<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Transitional//EN' 'http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd'>
<html dir="ltr" xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>JSON-LD - Linked Data Expression in JSON</title>
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />

<!--  
  === NOTA BENE ===
  For the three scripts below, if your spec resides on dev.w3 you can check them
  out in the same tree and use relative links so that they'll work offline,
   -->



<style>
.diff { font-weight:bold; color:#0a3; }
</style>
<style type="text/css">
/*****************************************************************
 * ReSpec CSS
 * Robin Berjon (robin at berjon dot com)
 * v0.05 - 2009-07-31
 *****************************************************************/


/* --- INLINES --- */
em.rfc2119 { 
    text-transform:     lowercase;
    font-variant:       small-caps;
    font-style:         normal;
    color:              #900;
}

h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
    border: none;
}

dfn {
    font-weight:    bold;
}

a.internalDFN {
    color:  inherit;
    border-bottom:  1px solid #99c;
    text-decoration:    none;
}

a.externalDFN {
    color:  inherit;
    border-bottom:  medium dotted #ccc;
    text-decoration:    none;
}

a.bibref {
    text-decoration:    none;
}

code {
    color:  #ff4500;
}


/* --- WEB IDL --- */
pre.idl {
    border-top: 1px solid #90b8de;
    border-bottom: 1px solid #90b8de;
    padding:    1em;
    line-height:    120%;
}

pre.idl::before {
    content:    "WebIDL";
    display:    block;
    width:      150px;
    background: #90b8de;
    color:  #fff;
    font-family:    initial;
    padding:    3px;
    font-weight:    bold;
    margin: -1em 0 1em -1em;
}

.idlType {
    color:  #ff4500;
    font-weight:    bold;
    text-decoration:    none;
}

/*.idlModule*/
/*.idlModuleID*/
/*.idlInterface*/
.idlInterfaceID {
    font-weight:    bold;
    color:  #005a9c;
}

.idlSuperclass {
    font-style: italic;
    color:  #005a9c;
}

/*.idlAttribute*/
.idlAttrType, .idlFieldType {
    color:  #005a9c;
}
.idlAttrName, .idlFieldName {
    color:  #ff4500;
}
.idlAttrName a, .idlFieldName a {
    color:  #ff4500;
    border-bottom:  1px dotted #ff4500;
    text-decoration: none;
}

/*.idlMethod*/
.idlMethType {
    color:  #005a9c;
}
.idlMethName {
    color:  #ff4500;
}
.idlMethName a {
    color:  #ff4500;
    border-bottom:  1px dotted #ff4500;
    text-decoration: none;
}

/*.idlParam*/
.idlParamType {
    color:  #005a9c;
}
.idlParamName {
    font-style: italic;
}

.extAttr {
    color:  #666;
}

/*.idlConst*/
.idlConstType {
    color:  #005a9c;
}
.idlConstName {
    color:  #ff4500;
}
.idlConstName a {
    color:  #ff4500;
    border-bottom:  1px dotted #ff4500;
    text-decoration: none;
}

/*.idlException*/
.idlExceptionID {
    font-weight:    bold;
    color:  #c00;
}

.idlTypedefID, .idlTypedefType {
    color:  #005a9c;
}

.idlRaises, .idlRaises a.idlType, .idlRaises a.idlType code, .excName a, .excName a code {
    color:  #c00;
    font-weight:    normal;
}

.excName a {
    font-family:    monospace;
}

.idlRaises a.idlType, .excName a.idlType {
    border-bottom:  1px dotted #c00;
}

.excGetSetTrue, .excGetSetFalse, .prmNullTrue, .prmNullFalse, .prmOptTrue, .prmOptFalse {
    width:  45px;
    text-align: center;
}
.excGetSetTrue, .prmNullTrue, .prmOptTrue { color:  #0c0; }
.excGetSetFalse, .prmNullFalse, .prmOptFalse { color:  #c00; }

.idlImplements a {
    font-weight:    bold;
}

dl.attributes, dl.methods, dl.constants, dl.fields {
    margin-left:    2em;
}

.attributes dt, .methods dt, .constants dt, .fields dt {
    font-weight:    normal;
}

.attributes dt code, .methods dt code, .constants dt code, .fields dt code {
    font-weight:    bold;
    color:  #000;
    font-family:    monospace;
}

.attributes dt code, .fields dt code {
    background:  #ffffd2;
}

.attributes dt .idlAttrType code, .fields dt .idlFieldType code {
    color:  #005a9c;
    background:  transparent;
    font-family:    inherit;
    font-weight:    normal;
    font-style: italic;
}

.methods dt code {
    background:  #d9e6f8;
}

.constants dt code {
    background:  #ddffd2;
}

.attributes dd, .methods dd, .constants dd, .fields dd {
    margin-bottom:  1em;
}

table.parameters, table.exceptions {
    border-spacing: 0;
    border-collapse:    collapse;
    margin: 0.5em 0;
    width:  100%;
}
table.parameters { border-bottom:  1px solid #90b8de; }
table.exceptions { border-bottom:  1px solid #deb890; }

.parameters th, .exceptions th {
    color:  #fff;
    padding:    3px 5px;
    text-align: left;
    font-family:    initial;
    font-weight:    normal;
    text-shadow:    #666 1px 1px 0;
}
.parameters th { background: #90b8de; }
.exceptions th { background: #deb890; }

.parameters td, .exceptions td {
    padding:    3px 10px;
    border-top: 1px solid #ddd;
    vertical-align: top;
}

.parameters tr:first-child td, .exceptions tr:first-child td {
    border-top: none;
}

.parameters td.prmName, .exceptions td.excName, .exceptions td.excCodeName {
    width:  100px;
}

.parameters td.prmType {
    width:  120px;
}

table.exceptions table {
    border-spacing: 0;
    border-collapse:    collapse;
    width:  100%;
}

/* --- TOC --- */
.toc a {
    text-decoration:    none;
}

a .secno {
    color:  #000;
}

/* --- TABLE --- */
table.simple {
    border-spacing: 0;
    border-collapse:    collapse;
    border-bottom:  3px solid #005a9c;
}

.simple th {
    background: #005a9c;
    color:  #fff;
    padding:    3px 5px;
    text-align: left;
}

.simple th[scope="row"] {
    background: inherit;
    color:  inherit;
    border-top: 1px solid #ddd;
}

.simple td {
    padding:    3px 10px;
    border-top: 1px solid #ddd;
}

.simple tr:nth-child(even) {
    background: #f0f6ff;
}

/* --- DL --- */
.section dd > p:first-child {
    margin-top: 0;
}

.section dd > p:last-child {
    margin-bottom: 0;
}

.section dd {
    margin-bottom:  1em;
}

.section dl.attrs dd, .section dl.eldef dd {
    margin-bottom:  0;
}

/* --- EXAMPLES --- */
pre.example {
    border-top: 1px solid #ff4500;
    border-bottom: 1px solid #ff4500;
    padding:    1em;
    margin-top: 1em;
}

pre.example::before {
    content:    "Example";
    display:    block;
    width:      150px;
    background: #ff4500;
    color:  #fff;
    font-family:    initial;
    padding:    3px;
    font-weight:    bold;
    margin: -1em 0 1em -1em;
}

/* --- EDITORIAL NOTES --- */
.issue {
    padding:    1em;
    margin: 1em 0em 0em;
    border: 1px solid #f00;
    background: #ffc;
}

.issue::before {
    content:    "Issue";
    display:    block;
    width:  150px;
    margin: -1.5em 0 0.5em 0;
    font-weight:    bold;
    border: 1px solid #f00;
    background: #fff;
    padding:    3px 1em;
}

.note {
    margin: 1em 0em 0em;
    padding:    1em;
    border: 2px solid #cff6d9;
    background: #e2fff0;
}

.note::before {
    content:    "Note";
    display:    block;
    width:  150px;
    margin: -1.5em 0 0.5em 0;
    font-weight:    bold;
    border: 1px solid #cff6d9;
    background: #fff;
    padding:    3px 1em;
}

/* --- Best Practices --- */
div.practice {
    border: solid #bebebe 1px;
    margin: 2em 1em 1em 2em;
}

span.practicelab {
    margin: 1.5em 0.5em 1em 1em;
    font-weight: bold;
    font-style: italic;
}

span.practicelab   { background: #dfffff; }

span.practicelab {
    position: relative;
    padding: 0 0.5em;
    top: -1.5em;
}

p.practicedesc {
    margin: 1.5em 0.5em 1em 1em;
}

@media screen {
    p.practicedesc {
        position: relative;
        top: -2em;
        padding: 0;
        margin: 1.5em 0.5em -1em 1em;
}

/* --- SYNTAX HIGHLIGHTING --- */
pre.sh_sourceCode {
  background-color: white;
  color: black;
  font-style: normal;
  font-weight: normal;
}

pre.sh_sourceCode .sh_keyword { color: #005a9c; font-weight: bold; }           /* language keywords */
pre.sh_sourceCode .sh_type { color: #666; }                            /* basic types */
pre.sh_sourceCode .sh_usertype { color: teal; }                             /* user defined types */
pre.sh_sourceCode .sh_string { color: red; font-family: monospace; }        /* strings and chars */
pre.sh_sourceCode .sh_regexp { color: orange; font-family: monospace; }     /* regular expressions */
pre.sh_sourceCode .sh_specialchar { color: 	#ffc0cb; font-family: monospace; }  /* e.g., \n, \t, \\ */
pre.sh_sourceCode .sh_comment { color: #A52A2A; font-style: italic; }         /* comments */
pre.sh_sourceCode .sh_number { color: purple; }                             /* literal numbers */
pre.sh_sourceCode .sh_preproc { color: #00008B; font-weight: bold; }       /* e.g., #include, import */
pre.sh_sourceCode .sh_symbol { color: blue; }                            /* e.g., *, + */
pre.sh_sourceCode .sh_function { color: black; font-weight: bold; }         /* function calls and declarations */
pre.sh_sourceCode .sh_cbracket { color: red; }                              /* block brackets (e.g., {, }) */
pre.sh_sourceCode .sh_todo { font-weight: bold; background-color: #00FFFF; }   /* TODO and FIXME */

/* Predefined variables and functions (for instance glsl) */
pre.sh_sourceCode .sh_predef_var { color: #00008B; }
pre.sh_sourceCode .sh_predef_func { color: #00008B; font-weight: bold; }

/* for OOP */
pre.sh_sourceCode .sh_classname { color: teal; }

/* line numbers (not yet implemented) */
pre.sh_sourceCode .sh_linenum { display: none; }

/* Internet related */
pre.sh_sourceCode .sh_url { color: blue; text-decoration: underline; font-family: monospace; }

/* for ChangeLog and Log files */
pre.sh_sourceCode .sh_date { color: blue; font-weight: bold; }
pre.sh_sourceCode .sh_time, pre.sh_sourceCode .sh_file { color: #00008B; font-weight: bold; }
pre.sh_sourceCode .sh_ip, pre.sh_sourceCode .sh_name { color: #006400; }

/* for Prolog, Perl... */
pre.sh_sourceCode .sh_variable { color: #006400; }

/* for LaTeX */
pre.sh_sourceCode .sh_italics { color: #006400; font-style: italic; }
pre.sh_sourceCode .sh_bold { color: #006400; font-weight: bold; }
pre.sh_sourceCode .sh_underline { color: #006400; text-decoration: underline; }
pre.sh_sourceCode .sh_fixed { color: green; font-family: monospace; }
pre.sh_sourceCode .sh_argument { color: #006400; }
pre.sh_sourceCode .sh_optionalargument { color: purple; }
pre.sh_sourceCode .sh_math { color: orange; }
pre.sh_sourceCode .sh_bibtex { color: blue; }

/* for diffs */
pre.sh_sourceCode .sh_oldfile { color: orange; }
pre.sh_sourceCode .sh_newfile { color: #006400; }
pre.sh_sourceCode .sh_difflines { color: blue; }

/* for css */
pre.sh_sourceCode .sh_selector { color: purple; }
pre.sh_sourceCode .sh_property { color: blue; }
pre.sh_sourceCode .sh_value { color: #006400; font-style: italic; }

/* other */
pre.sh_sourceCode .sh_section { color: black; font-weight: bold; }
pre.sh_sourceCode .sh_paren { color: red; }
pre.sh_sourceCode .sh_attribute { color: #006400; }

</style><style type="text/css">ol.algorithm { counter-reset:numsection; list-style-type: none; }
ol.algorithm li { margin: 0.5em 0; }
ol.algorithm li:before { font-weight: bold; counter-increment: numsection; content: counters(numsection, ".") ") "; }

</style><link href="http://www.w3.org/StyleSheets/TR/w3c-unofficial" rel="stylesheet" type="text/css" charset="utf-8" /><style type='text/css'>
.diff-old-a {
  font-size: smaller;
  color: red;
}

.diff-new { background-color: yellow; }
.diff-chg { background-color: lime; }
.diff-new:before,
.diff-new:after
    { content: "\2191" }
.diff-chg:before, .diff-chg:after
    { content: "\2195" }
.diff-old { text-decoration: line-through; background-color: #FBB; }
.diff-old:before,
.diff-old:after
    { content: "\2193" }
:focus { border: thin red solid}
</style>
</head>


<body style="display: inherit; ">
<div class="head">
<p>
</p>
<h1 class="title" id="title">
JSON-LD
-
Linked
Data
Expression
in
JSON
</h1>
<h2 id="subtitle">
A
Context-based
JSON
Serialization
for
Linked
Data
</h2>
<h2 id="unofficial-draft-15-june-2011">
Unofficial
Draft
<del class="diff-old">07
May
</del>
<ins class="diff-chg">15
June
</ins>
2011
</h2>
<dl>
<dt>
<del class="diff-old">Editor:
</del>
<ins class="diff-chg">Editors:
</ins>
</dt>
<dd>
<a href="http://digitalbazaar.com/">
Manu
Sporny
</a>,
<a href="http://digitalbazaar.com/">
Digital
Bazaar,
Inc.
</a>
</dd>
<dd>
<a href="http://greggkellogg.net/">
<ins class="diff-new">Gregg
Kellogg
</ins></a>,<ins class="diff-new">
Kellogg
Associates
</ins></dd>
<dt>
Authors:
</dt>
<dd>
<a href="http://webbackplane.com/">
Mark
Birbeck
</a>,
<a href="http://webbackplane.com/">
Backplane
Ltd.
</a>
</dd>
<dd>
<a href="http://digitalbazaar.com/">
Manu
Sporny
</a>,
<a href="http://digitalbazaar.com/">
Digital
Bazaar,
Inc.
</a>
</dd>
</dl>
<p>
This
document
is
also
available
in
this
non-normative
format:
<a href="diff-20110507.html">
diff
to
previous
version
</a>.
</p>
<p class="copyright">
This
document
is
licensed
under
a
<a class="subfoot" href="http://creativecommons.org/licenses/by/3.0/" rel="license">
Creative
Commons
Attribution
3.0
License
</a>.
</p>
<hr />
</div>
<div id="abstract" class="introductory section">
<h2>
Abstract
</h2>
<p>
Developers
that
embed
structured
data
in
their
Web
pages
can
choose
among
a
number
of
languages
such
as
RDFa
[
<cite>
<a class="bibref" rel="biblioentry" href="#bib-RDFA-CORE">
RDFA-CORE
</a>
</cite>
],
Microformats
[
<cite>
<a class="bibref" rel="biblioentry" href="#bib-MICROFORMATS">
MICROFORMATS
</a>
</cite>
]
and
Microdata
[
<cite>
<a class="bibref" rel="biblioentry" href="#bib-MICRODATA">
MICRODATA
</a>
</cite>
].
Each
of
these
structured
data
languages,
while
incompatible
at
the
syntax
level,
can
be
easily
mapped
to
RDF.
JSON
has
proven
to
be
a
highly
useful
object
serialization
and
messaging
format.
In
an
attempt
to
harmonize
the
representation
of
Linked
Data
in
JSON,
this
specification
outlines
a
common
JSON
representation
format
for
Linked
Data
that
can
be
used
to
represent
objects
specified
via
RDFa,
Microformats
and
Microdata.
</p>
</div>
<div id="sotd" class="introductory section">
<h2>
Status
of
This
Document
</h2>
<p>
This
document
is
merely
a
public
working
draft
of
a
potential
specification.
It
has
no
official
standing
of
any
kind
and
does
not
represent
the
support
or
consensus
of
any
standards
organisation.
</p>
<p>
This
document
is
an
experimental
work
in
progress.
</p>
</div>
<div id="toc" class="section">
<h2 class="introductory">
Table
of
Contents
</h2>
<ul class="toc">
<li class="tocline">
<a href="#introduction" class="tocxref">
<span class="secno">
1.
</span>
Introduction
</a>
<ul class="toc">
<li class="tocline">
<a href="#how-to-read-this-document" class="tocxref">
<span class="secno">
1.1
</span>
How
to
Read
this
Document
</a>
</li>
<li class="tocline">
<a href="#contributing" class="tocxref">
<span class="secno">
1.2
</span>
Contributing
</a>
</li>
</ul>
</li>
<li class="tocline">
<a href="#design-goals-and-rationale" class="tocxref">
<span class="secno">
2.
</span>
Design
Goals
and
Rationale
</a>
<ul class="toc">
<li class="tocline">
<a href="#goals" class="tocxref">
<span class="secno">
2.1
</span>
Goals
</a>
</li>
<li class="tocline">
<a href="#map-terms-to-iris" class="tocxref">
<span class="secno">
2.2
</span>
Map
Terms
to
IRIs
</a>
</li>
<li class="tocline">
<a href="#the-json-ld-context" class="tocxref">
<span class="secno">
2.3
</span>
The
JSON-LD
Context
</a>
</li>
<li class="tocline">
<a href="#unambiguous-identifiers-for-json" class="tocxref">
<span class="secno">
2.4
</span>
Unambiguous
Identifiers
for
JSON
</a>
</li>
<li class="tocline">
<a href="#mashing-up-vocabularies" class="tocxref">
<span class="secno">
2.5
</span>
Mashing
Up
Vocabularies
</a>
</li>
<li class="tocline">
<a href="#an-example-of-a-context" class="tocxref">
<span class="secno">
2.6
</span>
An
Example
of
a
Context
</a>
</li>
</ul>
</li>
<li class="tocline">
<a href="#markup-examples" class="tocxref">
<span class="secno">
3.
</span>
Markup
Examples
</a>
<ul class="toc">
<li class="tocline">
<a href="#rdfa" class="tocxref">
<span class="secno">
3.1
</span>
RDFa
</a>
</li>
<li class="tocline">
<a href="#microformats" class="tocxref">
<span class="secno">
3.2
</span>
Microformats
</a>
</li>
<li class="tocline">
<a href="#microdata" class="tocxref">
<span class="secno">
3.3
</span>
Microdata
</a>
</li>
</ul>
</li>
<li class="tocline">
<del class="diff-old">4.
The
JSON-LD
Processing
Algorithm
</del>
<a href="#markup-of-rdf-concepts" class="tocxref">
<span class="secno">
<del class="diff-old">5.
</del>
<ins class="diff-chg">4.
</ins>
</span>
Markup
of
RDF
Concepts
</a>
<ul class="toc">
<li class="tocline">
<a href="#iris" class="tocxref">
<span class="secno">
<del class="diff-old">5.1
</del>
<ins class="diff-chg">4.1
</ins>
</span>
IRIs
</a>
</li>
<li class="tocline">
<a href="#identifying-the-subject" class="tocxref">
<span class="secno">
<del class="diff-old">5.2
</del>
<ins class="diff-chg">4.2
</ins>
</span>
Identifying
the
Subject
</a>
</li>
<li class="tocline">
<a href="#specifying-the-type" class="tocxref">
<span class="secno">
<del class="diff-old">5.3
</del>
<ins class="diff-chg">4.3
</ins>
</span>
Specifying
the
Type
</a>
</li>
<li class="tocline">
<a href="#plain-literals" class="tocxref">
<span class="secno">
<del class="diff-old">5.4
</del>
<ins class="diff-chg">4.4
</ins>
</span>
Plain
Literals
</a>
</li>
<li class="tocline">
<a href="#language-specification-in-plain-literals" class="tocxref">
<span class="secno">
<del class="diff-old">5.5
</del>
<ins class="diff-chg">4.5
</ins>
</span>
Language
Specification
in
Plain
Literals
</a>
</li>
<li class="tocline">
<a href="#typed-literals" class="tocxref">
<span class="secno">
<del class="diff-old">5.6
</del>
<ins class="diff-chg">4.6
</ins>
</span>
Typed
Literals
</a>
</li>
<li class="tocline">
<a href="#multiple-objects-for-a-single-property" class="tocxref">
<span class="secno">
<del class="diff-old">5.7
</del>
<ins class="diff-chg">4.7
</ins>
</span>
Multiple
Objects
for
a
Single
Property
</a>
</li>
<li class="tocline">
<a href="#multiple-typed-literals-for-a-single-property" class="tocxref">
<span class="secno">
<del class="diff-old">5.8
</del>
<ins class="diff-chg">4.8
</ins>
</span>
Multiple
Typed
Literals
for
a
Single
Property
</a>
</li>
<li class="tocline">
<a href="#blank-nodes" class="tocxref">
<span class="secno">
<del class="diff-old">5.9
</del>
<ins class="diff-chg">4.9
</ins>
</span>
Blank
Nodes
</a>
</li>
</ul>
</li>
<li class="tocline">
<a href="#advanced-features" class="tocxref">
<span class="secno">
<del class="diff-old">6.
</del>
<ins class="diff-chg">5.
</ins>
</span>
Advanced
Features
</a>
<ul class="toc">
<li class="tocline">
<a href="#automatic-typing" class="tocxref">
<span class="secno">
<del class="diff-old">6.1
</del>
<ins class="diff-chg">5.1
</ins>
</span>
Automatic
Typing
</a>
</li>
<li class="tocline">
<a href="#type-coercion" class="tocxref">
<span class="secno">
<del class="diff-old">6.2
</del>
<ins class="diff-chg">5.2
</ins>
</span>
Type
Coercion
</a>
</li>
</ul>
</li>
<li class="tocline">
<a href="#the-json-ld-processing-algorithm" class="tocxref">
<span class="secno">
<ins class="diff-chg">6.
</ins></span><ins class="diff-chg">
The
JSON-LD
Processing
Algorithm
</ins></a><ul class="toc"><li class="tocline"><a href="#overview" class="tocxref"><span class="secno"><ins class="diff-chg">
6.1
</ins></span><ins class="diff-chg">
Overview
</ins></a></li><li class="tocline"><a href="#processing-algorithm-terms" class="tocxref"><span class="secno"><ins class="diff-chg">
6.2
</ins></span><ins class="diff-chg">
Processing
Algorithm
Terms
</ins></a></li><li class="tocline"><a href="#processing-tokens-and-keywords" class="tocxref"><span class="secno"><ins class="diff-chg">
6.3
</ins></span><ins class="diff-chg">
Processing
Tokens
and
Keywords
</ins></a></li><li class="tocline"><a href="#context" class="tocxref"><span class="secno"><ins class="diff-chg">
6.4
</ins></span><ins class="diff-chg">
Context
</ins></a><ul class="toc"><li class="tocline"><a href="#coerce" class="tocxref"><span class="secno"><ins class="diff-chg">
6.4.1
</ins></span><ins class="diff-chg">
Coerce
</ins></a></li></ul></li><li class="tocline"><a href="#chaining" class="tocxref"><span class="secno"><ins class="diff-chg">
6.5
</ins></span><ins class="diff-chg">
Chaining
</ins></a></li><li class="tocline"><a href="#iri-processing" class="tocxref"><span class="secno"><ins class="diff-chg">
6.6
</ins></span><ins class="diff-chg">
IRI
Processing
</ins></a></li></ul></li><li class="tocline"><a href="#sequence" class="tocxref">
<span class="secno">
7.
</span>
<ins class="diff-new">Sequence
</ins></a></li><li class="tocline"><a href="#best-practices" class="tocxref"><span class="secno"><ins class="diff-new">
8.
</ins></span>
Best
Practices
</a>
<ul class="toc">
<li class="tocline">
<a href="#javascript" class="tocxref">
<span class="secno">
<del class="diff-old">7.1
</del>
<ins class="diff-chg">8.1
</ins>
</span>
JavaScript
</a>
</li>
<li class="tocline">
<a href="#schema-less-databases" class="tocxref">
<span class="secno">
<del class="diff-old">7.2
</del>
<ins class="diff-chg">8.2
</ins>
</span>
Schema-less
Databases
</a>
</li>
</ul>
</li>
<li class="tocline">
<a href="#advanced-concepts" class="tocxref">
<span class="secno">
<del class="diff-old">8.
</del>
<ins class="diff-chg">9.
</ins>
</span>
Advanced
Concepts
</a>
<ul class="toc">
<li class="tocline">
<a href="#vocabulary-profiles" class="tocxref">
<span class="secno">
<del class="diff-old">8.1
</del>
<ins class="diff-chg">9.1
</ins>
</span>
Vocabulary
Profiles
</a>
</li>
<li class="tocline">
<a href="#disjoint-graphs" class="tocxref">
<span class="secno">
<del class="diff-old">8.2
</del>
<ins class="diff-chg">9.2
</ins>
</span>
Disjoint
Graphs
</a>
</li>
<li class="tocline">
<a href="#the-json-ld-api" class="tocxref">
<span class="secno">
<del class="diff-old">8.3
</del>
<ins class="diff-chg">9.3
</ins>
</span>
The
JSON-LD
API
</a>
<ul class="toc">
<li class="tocline">
<a href="#methods" class="tocxref">
<span class="secno">
<del class="diff-old">8.3.1
</del>
<ins class="diff-chg">9.3.1
</ins>
</span>
Methods
</a>
</li>
<li class="tocline">
<a href="#methods-1" class="tocxref">
<span class="secno">
<del class="diff-old">8.3.2
</del>
<ins class="diff-chg">9.3.2
</ins>
</span>
Methods
</a>
</li>
<li class="tocline">
<a href="#methods-2" class="tocxref">
<span class="secno">
<del class="diff-old">8.3.3
</del>
<ins class="diff-chg">9.3.3
</ins>
</span>
Methods
</a>
</li>
</ul>
</li>
</ul>
</li>
<li class="tocline">
<a href="#the-default-context" class="tocxref">
<span class="secno">
A.
</span>
The
Default
Context
</a>
</li>
<li class="tocline">
<a href="#acknowledgements" class="tocxref">
<span class="secno">
B.
</span>
Acknowledgements
</a>
</li>
<li class="tocline">
<a href="#references" class="tocxref">
<span class="secno">
C.
</span>
References
</a>
<ul class="toc">
<li class="tocline">
<a href="#normative-references" class="tocxref">
<span class="secno">
C.1
</span>
Normative
references
</a>
</li>
<li class="tocline">
<a href="#informative-references" class="tocxref">
<span class="secno">
C.2
</span>
Informative
references
</a>
</li>
</ul>
</li>
</ul>
</div>
<div id="introduction" class="section">
<h2>
<span class="secno">
1.
</span>
Introduction
</h2>
<p>
JSON-LD
is
designed
as
a
light-weight
syntax
that
can
be
used
to
express
Linked
Data.
It
is
primarily
intended
to
be
a
way
to
express
Linked
Data
in
Javascript
and
other
Web-based
programming
environments.
It
is
also
useful
when
building
interoperable
Web
Services
and
when
storing
Linked
Data
in
JSON-based
document
storage
engines.
It
is
practical
and
designed
to
be
as
simple
as
possible,
utilizing
the
large
number
of
JSON
parsers
and
existing
code
that
is
in
use
today.
It
is
designed
to
be
able
to
express
key-value
pairs,
RDF
data,
Microformats
data,
and
Microdata.
That
is,
it
supports
every
major
Web-based
structured
data
model
in
use
today.
It
does
not
require
anyone
to
change
their
JSON,
but
easily
add
meaning
by
adding
context
in
a
way
that
is
out-of-band.
The
syntax
is
designed
to
not
disturb
already
deployed
systems
running
on
JSON,
but
provide
a
smooth
migration
path
from
JSON
to
JSON
with
added
semantics.
Finally,
the
format
is
intended
to
be
fast
to
parse,
fast
to
generate,
stream-based
and
document-based
processing
compatible,
and
require
a
very
small
memory
footprint
in
order
to
operate.
</p>
<p>
<ins class="diff-new">JSON,
as
specified
in
[
</ins><cite><a class="bibref" rel="biblioentry" href="#bib-RFC4627"><ins class="diff-new">
RFC4627
</ins></a>
</cite>
<ins class="diff-new">],
is
a
simple
language
for
representing
objects
on
the
web.
Linked
Data
is
a
way
of
describing
content
across
different
documents,
or
web
resources.
Web
resources
are
described
using
</ins><a class="tref internalDFN" title="IRI" href="#dfn-iri"><ins class="diff-new">
IRI
</ins></a><ins class="diff-new">
s,
and
typically
are
dereferencable
entities
that
may
be
used
to
find
more
information,
creating
a
"web
of
knowledge".
JSON-LD
is
intended
to
be
a
simple
publishing
method
for
expressing
linked
data
in
JSON.
</ins>
</p>
<div id="how-to-read-this-document" class="section">
<h3>
<span class="secno">
1.1
</span>
How
to
Read
this
Document
</h3>
<p>
This
document
is
a
detailed
specification
for
a
serialization
of
JSON
for
Linked
data.
The
document
is
primarily
intended
for
the
following
audiences:
</p>
<ul>
<li>
Web
developers
that
want
to
understand
the
design
decisions
and
language
syntax
for
JSON-LD.
</li>
<li>
Software
developers
that
want
to
encode
Microformats,
RDFa,
or
Microdata
in
a
way
that
is
cross-language
compatible
via
JSON.
</li>
<li>
Software
developers
that
want
to
write
processors
for
JSON-LD.
</li>
</ul>
<p>
To
understand
this
specification
you
must
first
be
familiar
with
JSON,
which
is
detailed
in
[
<cite>
<a class="bibref" rel="biblioentry" href="#bib-RFC4627">
RFC4627
</a>
</cite>
]
and
<ins class="diff-new">RDF
as
described
in
</ins>
[
<cite>
<a class="bibref" rel="biblioentry" href="#bib-RDF-CONCEPTS">
RDF-CONCEPTS
</a>
</cite>
].
</p>
</div>
<div id="contributing" class="section">
<h3>
<span class="secno">
1.2
</span>
Contributing
</h3>
<p>
There
are
a
number
of
ways
that
one
may
participate
in
the
development
of
this
specification:
</p>
<ul>
<li>
All
comments
and
discussion
takes
place
on
the
public
mailing
list:
<a href="http://lists.w3.org/Archives/Public/public-linked-json/">
public-linked-json@w3.org
</a>
</li>
<li>
Specification
bugs
and
issues
should
be
reported
in
the
<a href="https://github.com/json-ld/json-ld.org/issues">
issue
tracker
</a>.
</li>
<li>
<a href="https://github.com/json-ld/json-ld.org/tree/main/spec">
Source
code
</a>
for
the
specification
can
be
found
on
Github.
</li>
<li>
The
<a href="http://webchat.freenode.net/?channels=#json-ld">
#json-ld
</a>
IRC
channel
is
available
for
real-time
discussion
on
irc.freenode.net.
</li>
</ul>
</div>
</div>
<div id="design-goals-and-rationale" class="section">
<h2>
<span class="secno">
2.
</span>
Design
Goals
and
Rationale
</h2>
<p>
The
following
section
outlines
the
design
goals
and
rationale
behind
the
JSON-LD
markup
language.
</p>
<div id="goals" class="section">
<h3>
<span class="secno">
2.1
</span>
Goals
</h3>
<p>
A
number
of
design
considerations
were
explored
during
the
creation
of
this
markup
language:
</p>
<dl>
<dt>
Simplicity
</dt>
<dd>
Developers
don't
need
to
know
RDF
in
order
to
use
the
basic
functionality
provided
by
JSON-LD.
</dd>
<dt>
Compatibility
</dt>
<dd>
The
JSON-LD
markup
should
be
100%
compatible
with
JSON.
</dd>
<dt>
Expressiveness
</dt>
<dd>
All
major
RDF
concepts
must
be
expressible
via
the
JSON-LD
syntax.
</dd>
<dt>
Terseness
</dt>
<dd>
The
JSON-LD
syntax
must
be
very
terse
and
human
readable.
</dd>
<dt>
Zero
Edits,
most
of
the
time
</dt>
<dd>
JSON-LD
provides
a
mechanism
that
allows
developers
to
specify
context
in
a
way
that
is
out-of-band.
This
allows
organizations
that
have
already
deployed
large
JSON-based
infrastructure
to
add
meaning
to
their
JSON
in
a
way
that
is
not
disruptive
to
their
day-to-day
operations
and
is
transparent
to
their
current
customers.
At
times,
mapping
JSON
to
RDF
can
become
difficult
-
in
these
instances,
rather
than
having
JSON-LD
support
esoteric
markup,
we
chose
not
to
support
the
use
case
and
support
a
simplified
syntax
instead.
So,
while
we
strive
for
Zero
Edits,
it
was
not
always
possible
without
adding
great
complexity
to
the
language.
</dd>
<dt>
Streaming
</dt>
<dd>
The
format
supports
both
document-based
and
stream-based
processing.
</dd>
</dl>
</div>
<div id="map-terms-to-iris" class="section">
<h3>
<span class="secno">
2.2
</span>
Map
Terms
to
IRIs
</h3>
<p>
<ins class="diff-new">An
Internationalized
Resource
Identifier
(
</ins><dfn title="IRI" id="dfn-iri"><abbr title="Internationalized Resource Identifier"><ins class="diff-new">
IRI
</ins></abbr></dfn><ins class="diff-new">
)
as
described
in
[
</ins><cite><a class="bibref" rel="biblioentry" href="#bib-RFC3987"><ins class="diff-new">
RFC3987
</ins></a></cite><ins class="diff-new">
],
is
a
mechanism
for
representing
unique
identifiers
on
the
web.
In
Linked
Data,
IRIs
(or
URI
references)
are
commonly
used
for
describing
entities
and
properties.
</ins></p><p>
Establishing
a
mechanism
to
map
JSON
values
to
IRIs
will
help
in
the
mapping
of
JSON
objects
to
RDF.
This
does
not
mean
that
JSON-LD
must
be
restrictive
in
declaring
a
set
of
terms,
rather,
experimentation
and
innovation
should
be
supported
as
part
of
the
core
design
of
JSON-LD.
There
are,
however,
a
number
of
very
small
design
criteria
that
can
ensure
that
developers
will
generate
good
RDF
data
that
will
create
value
for
the
greater
semantic
web
community
and
JSON/REST-based
Web
Services
community.
</p>
<p>
We
will
be
using
the
following
JSON
object
as
the
example
for
this
section:
</p>
<pre class="example">
{
  "a": "Person",
  "name": "Manu Sporny",
  "homepage": "http://manu.sporny.org/"
  "avatar": "http://twitter.com/account/profile_image/manusporny"
}
</pre>
</div>
<div id="the-json-ld-context" class="section">
<h3>
<span class="secno">
2.3
</span>
The
JSON-LD
Context
</h3>
<p>
A
context
is
used
<del class="diff-old">in
RDFa
</del>
to
allow
developers
to
use
aliases
for
<del class="diff-old">IRIs.
</del>
<a class="tref internalDFN" title="IRI" href="#dfn-iri">
<ins class="diff-chg">IRI
</ins></a><ins class="diff-chg">
s.
</ins>
The
semantic
web,
just
like
the
document-based
web,
uses
IRIs
for
unambiguous
identification.
The
idea
is
that
these
terms
mean
something,
which
you
will
eventually
want
to
query.
<ins class="diff-new">A
context
allows
the
expression
of
a
number
of
terms
which
map
directly
to
</ins><a class="tref internalDFN" title="IRI" href="#dfn-iri"><ins class="diff-new">
IRI
</ins></a><ins class="diff-new">
s.
For
example,
the
term
</ins><code><ins class="diff-new">
name
</ins></code><ins class="diff-new">
may
map
directly
to
the
IRI
</ins><code><ins class="diff-new">
http://xmlns.com/foaf/0.1/name
</ins></code>.<ins class="diff-new">
This
allows
JSON-LD
documents
to
be
constructed
using
common
JSON
syntax
of
using
simple
name/value
pairs.
</ins></p><p><ins class="diff-new">
To
reduce
the
number
of
different
terms
that
must
be
defined,
JSON-LD
also
allows
terms
to
be
used
to
expand
Compact
URIs
(
</ins><abbr title="Compact URI"><ins class="diff-new">
CURIE
</ins></abbr><ins class="diff-new">
).
</ins>
The
semantic
web
specifies
this
via
<em>
Vocabulary
Documents
<del class="diff-old">.
The
</del>
</em>,
<ins class="diff-chg">in
which
a
prefix
is
associated
with
a
document,
and
a
suffix
is
used
to
create
an
IRI
based
on
this
vocabulary.
For
example,
the
</ins>
IRI
<em>
http://xmlns.com/foaf/0.1/
</em>
specifies
a
Vocabulary
Document,
and
<strong>
name
</strong>
is
a
term
in
that
vocabulary.
Join
the
two
items
together
and
you
have
an
unambiguous
identifier
for
a
vocabulary
term.
The
Compact
URI
Expression,
or
short-form,
is
<code>
foaf:name
</code>
and
the
expanded-form
is
<code>
http://xmlns.com/foaf/0.1/name
</code>.
This
vocabulary
term
identifies
the
given
name
for
something,
for
example
-
a
person's
name.
</p>
<p>
Developers,
and
machines,
would
be
able
to
use
this
IRI
(plugging
it
directly
into
a
web
browser,
for
instance)
to
go
to
the
term
and
get
a
definition
of
what
the
term
means.
Much
like
we
can
use
WordNet
today
to
see
the
<a href="http://wordnetweb.princeton.edu/perl/webwn?s=definition">
definition
</a>
of
words
in
the
English
language.
Machines
need
the
same
sort
of
dictionary
of
terms,
and
URIs
provide
a
way
to
ensure
that
these
terms
are
unambiguous.
</p>
<p>
The
context
provides
a
collection
of
vocabulary
terms
that
can
be
used
for
a
JSON
object.
</p>
</div>
<div id="unambiguous-identifiers-for-json" class="section">
<h3>
<span class="secno">
2.4
</span>
Unambiguous
Identifiers
for
JSON
</h3>
<p>
If
a
set
of
terms,
like
<strong>
Person
</strong>,
<strong>
name
</strong>,
and
<strong>
homepage
</strong>,
are
defined
in
a
context,
and
that
context
is
used
to
resolve
the
names
in
JSON
objects,
machines
could
automatically
expand
the
terms
to
something
meaningful
and
unambiguous,
like
this:
</p>
<pre class="example">
{
  "<span class="diff">http://www.w3.org/1999/02/22-rdf-syntax-ns#type</span>": "<span class="diff">http://xmlns.com/foaf/0.1/Person</span>",
  "<span class="diff">http://xmlns.com/foaf/0.1/name</span>": "Manu Sporny",
  "<span class="diff">http://xmlns.com/foaf/0.1/homepage</span>": "http://manu.sporny.org"
  "<span class="diff">http://rdfs.org/sioc/ns#avatar</span>": "http://twitter.com/account/profile_image/manusporny"
}
</pre>
<p>
Doing
this
would
mean
that
JSON
would
start
to
become
unambiguously
machine-readable,
play
well
with
the
semantic
web,
and
basic
markup
wouldn't
be
that
much
more
complex
than
basic
JSON
markup.
A
win,
all
around.
</p>
</div>
<div id="mashing-up-vocabularies" class="section">
<h3>
<span class="secno">
2.5
</span>
Mashing
Up
Vocabularies
</h3>
<p>
Developers
would
also
benefit
by
allowing
other
vocabularies
to
be
used
automatically
with
their
JSON
API.
There
are
over
200
Vocabulary
Documents
that
are
available
for
use
on
the
Web
today.
Some
of
these
vocabularies
are:
</p>
<ul>
<li>
RDF
-
for
describing
information
about
objects
on
the
semantic
web.
</li>
<li>
RDFS
-
for
expressing
things
like
labels
and
comments.
</li>
<li>
XSD
-
for
specifying
basic
types
like
strings,
integers,
dates
and
times.
</li>
<li>
Dublin
Core
-
for
describing
creative
works.
</li>
<li>
FOAF
-
for
describing
social
networks.
</li>
<li>
Calendar
-
for
specifying
events.
</li>
<li>
SIOC
-
for
describing
discussions
on
blogs
and
websites.
</li>
<li>
CCrel
-
for
describing
Creative
Commons
and
other
types
of
licenses.
</li>
<li>
GEO
-
for
describing
geographic
location.
</li>
<li>
VCard
-
for
describing
organizations
and
people.
</li>
<li>
DOAP
-
for
describing
projects.
</li>
</ul>
<p>
Since
these
vocabularies
are
very
popular,
they
are
pre-defined
in
something
called
the
<a class="tref internalDFN" title="default_context" href="#dfn-default_context-1">
default
context
</a>,
which
is
a
set
of
vocabulary
prefixes
that
are
pre-loaded
in
all
JSON-LD
processors.
The
contents
of
the
<a class="tref internalDFN" title="default_context" href="#dfn-default_context-1">
default
context
</a>
are
provided
later
in
this
document.
Using
the
<a class="tref internalDFN" title="default_context" href="#dfn-default_context-1">
default
context
</a>
allows
developers
to
express
data
unambiguously,
like
so:
</p>
<pre class="example">
{
  "<span class="diff">rdf:type</span>": "<span class="diff">foaf:Person</span>",
  "<span class="diff">foaf:name</span>": "Manu Sporny",
  "<span class="diff">foaf:homepage</span>": "http://manu.sporny.org/",
  "<span class="diff">sioc:avatar</span>": "http://twitter.com/account/profile_image/manusporny"
}
</pre>
<p>
Developers
can
also
specify
their
own
Vocabulary
documents
by
modifying
the
<del class="diff-old">default
</del>
<a class="tref internalDFN" title="active_context" href="#dfn-active_context">
<ins class="diff-chg">active
</ins>
context
</a>
in-line
using
the
<code>
@context
</code>
keyword,
like
so:
</p>
<pre class="example">
{
  <span class="diff">"@context": { "myvocab": "http://example.org/myvocab#" }</span>,
  "a": "foaf:Person",
  "foaf:name": "Manu Sporny",
  "foaf:homepage": "http://manu.sporny.org/",
  "sioc:avatar": "http://twitter.com/account/profile_image/manusporny"<span class="diff">,
  "myvocab:personality": "friendly"</span>
}
</pre>
<p>
The
<code>
@context
</code>
keyword
is
used
to
change
how
the
JSON-LD
processor
evaluates
key-value
pairs.
In
this
case,
it
was
used
to
map
one
string
('myvocab')
to
another
string,
which
is
interpreted
as
a
<del class="diff-old">IRI.
</del>
<a class="tref internalDFN" title="IRI" href="#dfn-iri">
<ins class="diff-chg">IRI
</ins></a>.
In
the
example
above,
the
<code>
myvocab
</code>
string
is
replaced
with
"
<code>
http://example.org/myvocab#
</code>
"
when
it
is
detected.
In
the
example
above,
"
<code>
myvocab:personality
</code>
"
would
expand
to
"
<code>
http://example.org/myvocab#personality
</code>
".
</p>
<p>
This
mechanism
is
a
short-hand
for
RDF,
called
a
CURIE,
and
provides
developers
an
unambiguous
way
to
map
any
JSON
value
to
RDF.
</p>
<p>
</p>
</div>
<div id="an-example-of-a-context" class="section">
<h3>
<span class="secno">
2.6
</span>
An
Example
of
a
Context
</h3>
<p>
JSON-LD
strives
to
ensure
that
developers
don't
have
to
change
the
JSON
that
is
going
into
and
being
returned
from
their
Web
applications.
A
JSON-LD
aware
Web
Service
<em class="rfc2119" title="may">
may
</em>
define
a
known
context.
For
example,
the
following
<a class="tref internalDFN" title="default_context" href="#dfn-default_context-1">
default
context
</a>
could
apply
to
all
incoming
Web
Service
calls
previously
accepting
only
JSON
data:
</p>
<pre class="example">
{
  "@context": 
  {
    "@vocab": "http://example.org/default-vocab#",
    "@base": "http://example.org/baseurl/",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "dc": "http://purl.org/dc/terms/",
    "foaf": "http://xmlns.com/foaf/0.1/",
    "sioc": "http://rdfs.org/sioc/ns#",
    "cc": "http://creativecommons.org/ns#",
    "geo": "http://www.w3.org/2003/01/geo/wgs84_pos#",
    "vcard": "http://www.w3.org/2006/vcard/ns#",
    "cal": "http://www.w3.org/2002/12/cal/ical#",
    "doap": "http://usefulinc.com/ns/doap#",
    "Person": "http://xmlns.com/foaf/0.1/Person",
    "name": "http://xmlns.com/foaf/0.1/name",
    "homepage": "http://xmlns.com/foaf/0.1/homepage"
    "@coerce": 
    {
<del class="diff-old">      "xsd:anyURI": ["foaf:homepage", "foaf:member"],
</del>
<ins class="diff-chg">      "xsd:anyURI": ["rdf:type", "rdf:rest", "foaf:homepage", "foaf:member"],
</ins>
      "xsd:integer": "foaf:age"
    }
  }
}
</pre>
<p>
The
<code>
@vocab
</code>
string
is
a
special
keyword
that
states
that
any
term
that
doesn't
resolve
to
a
term
or
a
prefix
should
be
appended
to
the
<code>
@vocab
</code>
IRI.
This
is
done
to
ensure
that
terms
can
be
transformed
to
an
IRI
at
all
times.
</p>
<p>
The
<code>
@base
</code>
string
is
a
special
keyword
that
states
that
any
relative
IRI
<em class="rfc2119" title="must">
must
</em>
be
appended
to
the
string
specified
by
<code>
@base
</code>.
</p>
<p>
The
<code>
@coerce
</code>
keyword
is
used
to
specify
type
<del class="diff-old">coersion
</del>
<ins class="diff-chg">coercion
</ins>
rules
for
the
data.
For
each
key
in
the
map,
the
key
is
the
type
to
be
coerced
to
and
the
value
is
the
vocabulary
term
to
be
coerced.
Type
<del class="diff-old">coersion
</del>
<ins class="diff-chg">coercion
</ins>
for
the
key
<code>
xsd:anyURI
</code>
asserts
that
all
vocabulary
terms
listed
should
undergo
coercion
to
an
IRI,
including
<code>
@base
</code>
processing
for
relative
IRIs
and
CURIE
processing
for
compact
URI
Expressions
<del class="diff-old">like
</del>
<ins class="diff-chg">such
as
</ins>
<code>
foaf:homepage
</code>.
</p>
</div>
</div>
<div id="markup-examples" class="section">
<h2>
<span class="secno">
3.
</span>
Markup
Examples
</h2>
<p>
The
JSON-LD
markup
examples
below
demonstrate
how
JSON-LD
can
be
used
to
express
semantic
data
marked
up
in
other
languages
such
as
RDFa,
Microformats,
and
Microdata.
These
sections
are
merely
provided
as
proof
that
JSON-LD
is
very
flexible
in
what
it
can
express
across
different
Linked
Data
approaches.
</p>
<div id="rdfa" class="section">
<h3>
<span class="secno">
3.1
</span>
RDFa
</h3>
<p>
The
following
example
describes
three
people
with
their
respective
names
and
homepages.
</p>
<pre class="example">
&lt;div <span class="diff">prefix="foaf: http://xmlns.com/foaf/0.1/"</span>&gt;
   &lt;ul&gt;
      &lt;li <span class="diff">typeof="foaf:Person"</span>&gt;
        &lt;a <span class="diff">rel="foaf:homepage" href="http://example.com/bob/" property="foaf:name" </span>&gt;Bob&lt;/a&gt;
      &lt;/li&gt;
      &lt;li <span class="diff">typeof="foaf:Person"</span>&gt;
        &lt;a <span class="diff">rel="foaf:homepage" href="http://example.com/eve/" property="foaf:name" </span>&gt;Eve&lt;/a&gt;
      &lt;/li&gt;
      &lt;li <span class="diff">typeof="foaf:Person"</span>&gt;
        &lt;a <span class="diff">rel="foaf:homepage" href="http://example.com/manu/" property="foaf:name" </span>&gt;Manu&lt;/a&gt;
      &lt;/li&gt;
   &lt;/ul&gt;
&lt;/div&gt;
</pre>
<p>
An
example
JSON-LD
implementation
is
described
below,
however,
there
are
other
ways
to
mark-up
this
information
such
that
the
context
is
not
repeated.
</p>
<pre class="example">
[
 {
   "@": "_:bnode1",
   "a": "foaf:Person",
   "foaf:homepage": "http://example.com/bob/",
   "foaf:name": "Bob"
 },
 {
   "@": "_:bnode2",
   "a": "foaf:Person",
   "foaf:homepage": "http://example.com/eve/",
   "foaf:name": "Eve"
 },
 {
   "@": "_:bnode3",
   "a": "foaf:Person",
   "foaf:homepage": "http://example.com/manu/",
   "foaf:name": "Manu"
 }
]
</pre>
</div>
<div id="microformats" class="section">
<h3>
<span class="secno">
3.2
</span>
Microformats
</h3>
<p>
The
following
example
uses
a
simple
Microformats
hCard
example
to
express
how
the
Microformat
is
represented
in
JSON-LD.
</p>
<pre class="example">
&lt;div class="vcard"&gt;
 &lt;a class="url fn" href="http://tantek.com/"&gt;Tantek Çelik&lt;/a&gt;
&lt;/div&gt;
</pre>
<p>
The
representation
of
the
hCard
expresses
the
Microformat
terms
in
the
context
and
uses
them
directly
for
the
<code>
url
</code>
and
<code>
fn
</code>
properties.
Also
note
that
the
Microformat
to
JSON-LD
processor
has
generated
the
proper
URL
type
for
<code>
http://tantek.com
</code>.
</p>
<pre class="example">
{
  "@context": 
  {
    "vcard": "http://microformats.org/profile/hcard#vcard",
    "url": "http://microformats.org/profile/hcard#url",
    "fn": "http://microformats.org/profile/hcard#fn",
    "@coerce": { "xsd:anyURI": "url" }
  },
  "@": "_:bnode1",
  "a": "vcard",
  "url": "http://tantek.com/",
  "fn": "Tantek Çelik"
}
</pre>
</div>
<div id="microdata" class="section">
<h3>
<span class="secno">
3.3
</span>
Microdata
</h3>
<p>
The
Microdata
example
below
expresses
book
information
as
a
Microdata
Work
item.
</p>
<pre class="example">
&lt;dl itemscope
    itemtype="http://purl.org/vocab/frbr/core#Work"
    itemid="http://purl.oreilly.com/works/45U8QJGZSQKDH8N"&gt;
 &lt;dt&gt;Title&lt;/dt&gt;
 &lt;dd&gt;&lt;cite itemprop="http://purl.org/dc/terms/title"&gt;Just a Geek&lt;/cite&gt;&lt;/dd&gt;
 &lt;dt&gt;By&lt;/dt&gt;
 &lt;dd&gt;&lt;span itemprop="http://purl.org/dc/terms/creator"&gt;Wil Wheaton&lt;/span&gt;&lt;/dd&gt;
 &lt;dt&gt;Format&lt;/dt&gt;
 &lt;dd itemprop="http://purl.org/vocab/frbr/core#realization"
     itemscope
     itemtype="http://purl.org/vocab/frbr/core#Expression"
     itemid="http://purl.oreilly.com/products/9780596007683.BOOK"&gt;
  &lt;link itemprop="http://purl.org/dc/terms/type" href="http://purl.oreilly.com/product-types/BOOK"&gt;
  Print
 &lt;/dd&gt;
 &lt;dd itemprop="http://purl.org/vocab/frbr/core#realization"
     itemscope
     itemtype="http://purl.org/vocab/frbr/core#Expression"
     itemid="http://purl.oreilly.com/products/9780596802189.EBOOK"&gt;
  &lt;link itemprop="http://purl.org/dc/terms/type" href="http://purl.oreilly.com/product-types/EBOOK"&gt;
  Ebook
 &lt;/dd&gt;
&lt;/dl&gt;
</pre>
<p>
Note
that
the
JSON-LD
representation
of
the
Microdata
information
stays
true
to
the
desires
of
the
Microdata
community
to
avoid
contexts
and
instead
refer
to
items
by
their
full
IRI.
</p>
<pre class="example">
[
  {
    "@": "http://purl.oreilly.com/works/45U8QJGZSQKDH8N",
    "a": "http://purl.org/vocab/frbr/core#Work",
    "http://purl.org/dc/terms/title": "Just a Geek",
    "http://purl.org/dc/terms/creator": "Whil Wheaton",
    "http://purl.org/vocab/frbr/core#realization": 
      ["http://purl.oreilly.com/products/9780596007683.BOOK", "http://purl.oreilly.com/products/9780596802189.EBOOK"]
  },
  {
    "@": "http://purl.oreilly.com/products/9780596007683.BOOK",
    "a": "http://purl.org/vocab/frbr/core#Expression",
    "http://purl.org/dc/terms/type": "http://purl.oreilly.com/product-types/BOOK"
  },
  {
    "@": "http://purl.oreilly.com/products/9780596802189.EBOOK",
    "a": "http://purl.org/vocab/frbr/core#Expression",
    "http://purl.org/dc/terms/type": "http://purl.oreilly.com/product-types/EBOOK"
  }
]
</pre>
</div>
</div>
<del class="diff-old">4.
The
JSON-LD
Processing
Algorithm
The
processing
algorithm
described
in
this
section
is
provided
in
order
to
demonstrate
how
one
might
implement
a
JSON-LD
processor.
Conformant
implementations
are
only
required
to
produce
the
same
type
and
number
of
triples
during
the
output
process
and
are
not
required
to
implement
the
algorithm
exactly
as
described.
The
Processing
Algorithm
is
a
work
in
progress,
there
are
still
major
bugs
in
the
algorithm
and
it's
difficult
to
follow.
It's
provided
only
to
very
early
implementers
to
give
them
an
idea
of
how
to
implement
a
processor.
Processing
Algorithm
Terms
default
context
-
a
context
that
is
specified
to
the
JSON-LD
processing
algorithm
before
processing
begins.
default
graph
-
the
destination
graph
for
all
triples
generated
by
JSON-LD
markup.
active
subject
-
the
currently
active
subject
that
the
processor
should
use
when
generating
triples.
inherited
subject
-
a
subject
that
was
detected
at
a
higher
level
of
processing
to
be
used
to
generate
a
triple
once
a
current
subject
is
discovered
or
generated.
active
property
-
the
currently
active
property
that
the
processor
should
use
when
generating
triples.
inherited
property
-
a
property
that
was
detected
at
a
higher
level
of
processing
to
be
used
to
generate
a
triple
once
a
current
subject
is
discovered
or
generated.
active
object
-
the
currently
active
object
that
the
processor
should
use
when
generating
triples.
active
context
-
a
context
that
is
used
to
resolve
CURIEs
while
the
processing
algorithm
is
running.
The
active
context
is
the
top-most
item
on
the
active
context
stack.
local
context
-
a
context
that
is
specified
at
the
JSON
associative-array
level,
specified
via
the
@context
keyword.
list
of
incomplete
triples
-
A
list
of
triples
that
have
yet
to
have
their
subject
set.
list
of
unprocessed
items
-
A
list
of
objects
that
cannot
be
processed
until
a
local
context
is
detected
or
the
end
of
the
current
associative-array
is
detected.
processor
state
-
the
processor
state,
which
includes
the
active
context
stack,
current
subject
,
current
property
,
list
of
incomplete
triples
,
and
the
list
of
unprocessed
items
.
Processing
Tokens
and
Keywords
@context
-
Used
to
set
the
active
context.
@base
-
Used
to
set
the
base
IRI
for
all
object
IRIs
affected
by
the
active
context.
@vocab
-
Used
to
set
the
base
IRI
for
all
property
IRIs
affected
by
the
active
context.
@coerce
-
Used
to
specify
type
coercion
rules.
@literal
-
Used
to
specify
a
literal
value.
@iri
-
Used
to
specify
an
IRI
value.
@language
-
Used
to
specify
the
language
for
a
literal.
@datatype
-
Used
to
specify
the
datatype
for
a
literal.
:
-
The
separator
for
CURIEs
when
used
in
JSON
keys
or
JSON
values.
@
-
Sets
the
active
subjects.
a
-
Used
to
set
the
rdf:type
of
the
active
subjects.
The
algorithm
below
is
designed
for
streaming
(SAX-based)
implementations.
Implementers
will
find
that
non-streaming
(document-based)
implementations
will
be
much
easier
to
implement
as
full
access
to
the
JSON
object
model
eliminates
some
of
the
steps
that
are
necessary
for
streaming
implementations.
A
conforming
JSON-LD
processor
must
implement
a
processing
algorithm
that
results
in
the
same
default
graph
that
the
following
algorithm
generates:
Push
the
default
context
onto
the
active
context
stack.
If
an
associative
array
is
detected,
create
a
new
processor
state
.
Copy
the
current
context
stack
to
the
newly
created
processor
state
.
Push
the
active
context
onto
the
newly
created
processor
state
's
active
context
stack.
For
each
key-value
pair
in
the
associative
array,
using
the
newly
created
processor
state
do
the
following:
If
a
@context
keyword
is
found,
the
processor
merges
each
key-value
pair
in
the
local
context
into
the
active
context
,
overwriting
any
duplicate
values
in
the
active
context
.
If
the
@coerce
key
is
found,
the
processor
merges
each
key-value
pair
in
the
local
context
's
@coerce
mapping
into
the
active
context
's
@coerce
mapping,
overwriting
any
duplicate
values
in
the
active
context
's
@coerce
mapping.
Process
each
object
in
the
list
of
unprocessed
items
,
starting
at
Step
2.2
.
If
the
local
context
has
not
been
detected,
the
current
key-value
pair
is
placed
into
the
list
of
unprocessed
items
and
processing
proceeds
to
the
next
key-value
pair.
Otherwise,
if
the
local
context
is
known
perform
the
following
steps:
If
a
@
key
is
found,
the
processor
sets
the
active
subject
to
the
value
after
Object
Processing
has
been
performed.
If
the
inherited
subject
and
inherited
property
values
are
specified,
generate
a
triple
using
the
inherited
subject
for
the
subject,
the
inherited
property
for
the
property,
and
the
active
subject
for
the
object.
If
there
are
any
triples
in
the
list
of
incomplete
triples
,
complete
each
triple
using
the
active
subject
as
the
subject
for
each
triple.
If
an
a
key
is
found,
set
the
active
property
to
http://www.w3.org/1999/02/22-rdf-syntax-ns#type
.
If
a
key
that
is
not
@context
,
@
,
or
a
,
set
the
active
property
by
performing
Property
Processing
on
the
key.
If
the
value
is
not
an
array,
set
the
active
object
by
performing
Object
Processing
on
the
value.
Generate
a
triple
representing
the
active
subject
,
the
active
property
and
the
active
object
.
If
the
value
is
an
associative
array,
then
process
the
value
starting
at
Step
2
.
If
the
value
is
a
regular
array,
then
process
the
value
starting
at
Step
3
ensuring
that
the
active
subject
and
the
active
property
are
copied
to
a
newly
created
processor
state
.
If
the
end
of
the
associative
array
is
detected,
and
a
active
subject
was
not
discovered,
then:
Generate
a
blank
node
identifier
and
set
it
as
the
active
subject
.
Complete
any
previously
incomplete
triples
by
running
all
substeps
of
Step
2.2.1
.
If
the
end
of
the
associative
array
is
detected,
and
a
local
context
was
not
discovered,
then
assume
that
the
active
context
is
unmodified
and
run
all
substeps
of
Step
2.2
on
the
list
of
unprocessed
items
.
If
a
regular
array
is
detected,
process
each
value
in
the
array
by
doing
the
following:
If
the
value
is
an
associative
array,
processes
per
Step
2
,
ensuring
to
set
the
inherited
subject
to
the
active
subject
and
the
inherited
property
to
the
active
property
in
the
newly
created
processor
state
.
If
the
value
is
not
an
array,
set
the
active
object
by
performing
Object
Processing
on
the
value.
Generate
a
triple
representing
the
active
subject
,
the
active
property
and
the
active
object
and
place
it
into
the
default
graph
.
If
the
value
is
a
regular
array,
should
we
support
RDF
List/Sequence
Processing?
If
the
value
is
a
regular
array,
should
we
support
RDF
List/Sequence
generation
of
triples?
For
example,
would
implementing
this
be
worth
the
more
complex
processing
rules:
"ex:orderedItems"
:
[["one",
"two",
"three"]]
</del>
<div id="markup-of-rdf-concepts" class="section">
<h2>
<span class="secno">
<del class="diff-old">5.
</del>
<ins class="diff-chg">4.
</ins>
</span>
Markup
of
RDF
Concepts
</h2>
<p>
JSON-LD
is
designed
to
ensure
that
most
Linked
Data
concepts
can
be
marked
up
in
a
way
that
is
simple
to
understand
and
author
by
Web
developers.
In
many
cases,
Javascript
objects
can
become
Linked
Data
with
the
simple
addition
of
a
context.
Since
RDF
is
also
an
important
sub-community
of
the
Linked
Data
movement,
it
is
important
that
all
RDF
concepts
are
well-represented
in
this
specification.
This
section
details
how
each
RDF
concept
can
be
expressed
in
JSON-LD.
</p>
<div id="iris" class="section">
<h3>
<span class="secno">
<del class="diff-old">5.1
</del>
<ins class="diff-chg">4.1
</ins>
</span>
IRIs
</h3>
<p>
Expressing
IRIs
are
fundamental
to
Linked
Data
as
that
is
how
most
subjects
and
many
objects
are
identified.
IRIs
can
be
expressed
in
a
variety
of
different
ways
in
JSON-LD.
</p>
<ol>
<li>
In
general,
an
IRI
is
generated
if
it
is
in
the
key
position
in
an
associative
array.
There
are
special
rules
for
processing
keys
in
<code>
@context
</code>
and
when
dealing
with
keys
that
start
with
the
<code>
@
</code>
character.
</li>
<li>
An
IRI
is
generated
for
the
value
specified
using
<code>
@
</code>,
if
it
is
a
string.
</li>
<li>
An
IRI
is
generated
for
the
value
specified
using
<code>
a
</code>.
</li>
<li>
An
IRI
is
generated
for
the
value
specified
using
the
<code>
@iri
</code>
keyword.
</li>
<li>
An
IRI
is
generated
when
there
are
<code>
@coerce
</code>
rules
in
effect
for
<code>
xsd:anyURI
</code>
for
a
particular
vocabulary
term.
</li>
</ol>
<p>
An
example
of
IRI
generation
for
a
key
outside
of
a
<code>
@context
</code>:
</p>
<pre class="example">
{
...
  "<span class="diff">http://xmlns.com/foaf/0.1/name</span>": "Manu Sporny",
...
}
</pre>
<p>
In
the
example
above,
the
key
<code>
http://xmlns.com/foaf/0.1/name
</code>
is
interpreted
as
an
IRI,
as
opposed
to
being
interpreted
as
a
string..
</p>
<p>
<ins class="diff-new">Term
expansion
occurs
for
IRIs
if
a
term
is
defined
within
the
</ins><a class="tref internalDFN" title="active_context" href="#dfn-active_context"><ins class="diff-new">
active
context
</ins></a>:</p><pre class="example"><ins class="diff-new">
{
  "<span class="diff">@context</span>": {"<span class="diff">name</span>": "<span class="diff">http://xmlns.com/foaf/0.1/name</span>"},
...
  "<span class="diff">name</span>": "Manu Sporny",
...
}
</ins></pre><p>
CURIE
expansion
also
occurs
for
keys
in
JSON-LD:
</p>
<pre class="example">
{
...
  "<span class="diff">foaf:name</span>": "Manu Sporny",
...
}
</pre>
<p>
<code>
foaf:name
</code>
above
will
automatically
expand
out
to
the
IRI
<code>
http://xmlns.com/foaf/0.1/name
</code>.
</p>
<p>
An
IRI
is
generated
when
a
value
is
associated
with
a
key
using
the
<code>
@iri
</code>
keyword:
</p>
<pre class="example">
{
...
  "foaf:homepage": { "<span class="diff">@iri</span>": "http://manu.sporny.org" }
...
}
</pre>
<p>
If
type
coercion
rules
are
specified
in
the
<code>
@context
</code>
for
a
particular
vocabulary
term,
an
IRI
is
generated:
</p>
<pre class="example">
{<span class="diff">
  "@context": 
  { 
    "@coerce": 
    {
      "xsd:anyURI": "foaf:homepage"
    } 
  }</span>
...
  "foaf:homepage": "http://manu.sporny.org",
...
}
</pre>
</div>
<div id="identifying-the-subject" class="section">
<h3>
<span class="secno">
<del class="diff-old">5.2
</del>
<ins class="diff-chg">4.2
</ins>
</span>
Identifying
the
Subject
</h3>
<p>
A
subject
is
declared
using
the
<code>
@
</code>
key.
The
subject
is
the
first
piece
of
information
needed
by
the
JSON-LD
processor
in
order
to
create
the
(subject,
property,
object)
tuple,
also
known
as
a
triple.
</p>
<pre class="example">
{
...
  "<span class="diff">@</span>": "<span class="diff">http://example.org/people#joebob</span>",
...
}
</pre>
<p>
The
example
above
would
set
the
subject
to
the
IRI
<code>
http://example.org/people#joebob
</code>.
</p>
</div>
<div id="specifying-the-type" class="section">
<h3>
<span class="secno">
<del class="diff-old">5.3
</del>
<ins class="diff-chg">4.3
</ins>
</span>
Specifying
the
Type
</h3>
<p>
The
type
of
a
particular
subject
can
be
specified
using
the
<code>
a
</code>
key.
Specifying
the
type
in
this
way
will
generate
a
triple
of
the
form
(subject,
type,
type-url).
</p>
<pre class="example">
{
...
  "@": "http://example.org/people#joebob",
  "<span class="diff">a</span>": "<span class="diff">http://xmlns.com/foaf/0.1/Person</span>",
...
}
</pre>
<p>
The
example
above
would
generate
the
following
triple
(in
N-Triples
notation):
</p>
<pre class="example">
&lt;http://example.org/people#joebob&gt; 
   &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#type&gt;
&lt;http://xmlns.com/foaf/0.1/Person&gt;
.
</pre>
</div>
<div id="plain-literals" class="section">
<h3>
<span class="secno">
<del class="diff-old">5.4
</del>
<ins class="diff-chg">4.4
</ins>
</span>
Plain
Literals
</h3>
<p>
Regular
text
strings
are
called
<del class="diff-old">"plain
literals"
</del>
<ins class="diff-chg">a
</ins><dfn title="plain_literal" id="dfn-plain_literal"><ins class="diff-chg">
plain
literal
</ins></dfn>
in
RDF
and
are
easily
expressed
using
regular
JSON
strings.
</p>
<pre class="example">
{
...
  "foaf:name": "<span class="diff">Mark Birbeck</span>",
...
}
</pre>
</div>
<div id="language-specification-in-plain-literals" class="section">
<h3>
<span class="secno">
<del class="diff-old">5.5
</del>
<ins class="diff-chg">4.5
</ins>
</span>
Language
Specification
in
Plain
Literals
</h3>
<p>
JSON-LD
makes
an
assumption
that
<a class="tref internalDFN" title="plain_literal" href="#dfn-plain_literal">
plain
<del class="diff-old">literals
</del>
<ins class="diff-chg">literal
</ins></a><ins class="diff-chg">
s
</ins>
with
associated
language
encoding
information
is
not
very
common
when
used
in
JavaScript
and
Web
Services.
Thus,
it
takes
a
little
more
effort
to
express
plain
literals
in
a
specified
language.
</p>
<pre class="example">
{
...
  "foaf:name": <span class="diff">
  {
    "@literal": "花澄",
    "@language": "ja"
  }</span>
...
}
</pre>
<p>
The
example
above
would
generate
a
<a class="tref internalDFN" title="plain_literal" href="#dfn-plain_literal">
plain
literal
</a>
for
<em>
花澄
</em>
and
associate
the
<code>
ja
</code>
language
tag
with
the
triple
that
is
generated.
Languages
<em class="rfc2119" title="must">
must
</em>
be
expressed
in
[
<cite>
<a class="bibref" rel="biblioentry" href="#bib-BCP47">
BCP47
</a>
</cite>
]
format.
</p>
</div>
<div id="typed-literals" class="section">
<h3>
<span class="secno">
<del class="diff-old">5.6
</del>
<ins class="diff-chg">4.6
</ins>
</span>
Typed
Literals
</h3>
<p>
<ins class="diff-new">A
</ins><dfn title="typed_literal" id="dfn-typed_literal"><ins class="diff-new">
typed
literal
</ins></dfn><ins class="diff-new">
is
indicated
by
attaching
a
IRI
to
the
end
of
a
</ins><a class="tref internalDFN" title="plain_literal" href="#dfn-plain_literal"><ins class="diff-new">
plain
literal
</ins></a>,<ins class="diff-new">
and
this
IRI
indicates
the
literal's
datatype.
</ins>
Literals
may
<del class="diff-old">also
</del>
be
typed
in
JSON-LD
in
<del class="diff-old">two
</del>
<ins class="diff-chg">three
</ins>
ways:
</p>
<ol>
<li>
By
utilizing
the
<code>
@coerce
</code>
keyword.
</li>
<li>
By
utilizing
the
expanded
form
for
specifying
objects.
</li>
<li>
<ins class="diff-new">By
using
a
native
JSON
datatype.
</ins></li>
</ol>
<p>
The
first
example
uses
the
<code>
@coerce
</code>
keyword
to
express
a
typed
literal:
</p>
<pre class="example">
{<span class="diff">
  "@context": 
  { 
    "@coerce": 
    {
      "xsd:dateTime": "dc:modified"
    }
  }</span>
...
  "dc:modified": "2010-05-29T14:17:39+02:00",
...
}
</pre>
<p>
The
second
example
uses
the
expanded
form
for
specifying
objects:
</p>
<pre class="example">
{
...
  "dc:modified": <span class="diff">
  {
    "@literal": "2010-05-29T14:17:39+02:00",
    "@datatype": "xsd:dateTime"
  }</span>
...
}
</pre>
<p>
Both
examples
above
would
generate
an
object
with
the
literal
value
of
<code>
2010-05-29T14:17:39+02:00
</code>
and
the
datatype
of
<code>
http://www.w3.org/2001/XMLSchema#dateTime
</code>.
</p>
</div>
<div id="multiple-objects-for-a-single-property" class="section">
<h3>
<span class="secno">
<del class="diff-old">5.7
</del>
<ins class="diff-chg">4.7
</ins>
</span>
Multiple
Objects
for
a
Single
Property
</h3>
<p>
A
JSON-LD
author
can
express
multiple
triples
in
a
compact
way
by
using
arrays.
If
a
subject
has
multiple
values
for
the
same
property,
the
author
<em class="rfc2119" title="may">
may
</em>
express
each
property
as
an
array.
</p>
<pre class="example">
{
...
  "@": "http://example.org/people#joebob",
  "foaf:nick": <span class="diff">["joe", "bob", "jaybee"]</span>,
...
}
</pre>
<p>
The
markup
shown
above
would
generate
the
following
triples:
</p>
<pre class="example">
&lt;http://example.org/people#joebob&gt; 
   &lt;http://xmlns.com/foaf/0.1/nick&gt;
      "joe" .
&lt;http://example.org/people#joebob&gt; 
   &lt;http://xmlns.com/foaf/0.1/nick&gt;
      "bob" .
&lt;http://example.org/people#joebob&gt; 
   &lt;http://xmlns.com/foaf/0.1/nick&gt;
"jaybee"
.
</pre>
</div>
<div id="multiple-typed-literals-for-a-single-property" class="section">
<h3>
<span class="secno">
<del class="diff-old">5.8
</del>
<ins class="diff-chg">4.8
</ins>
</span>
Multiple
Typed
Literals
for
a
Single
Property
</h3>
<p>
Multiple
<a class="tref internalDFN" title="typed_literal" href="#dfn-typed_literal">
typed
<del class="diff-old">literals
</del>
<ins class="diff-chg">literal
</ins></a><ins class="diff-chg">
s
</ins>
may
also
be
expressed
using
the
expanded
form
for
objects:
</p>
<pre class="example">
{
...
  "@": "http://example.org/articles/8",
  "dcterms:modified": <span class="diff">
  [
    {
      "@literal": "2010-05-29T14:17:39+02:00",
      "@datatype": "xsd:dateTime"
    },
    {
      "@literal": "2010-05-30T09:21:28-04:00",
      "@datatype": "xsd:dateTime"
    }
  ]</span>
...
}
</pre>
<p>
The
markup
shown
above
would
generate
the
following
triples:
</p>
<pre class="example">
&lt;http://example.org/articles/8&gt; 
   &lt;http://purl.org/dc/terms/modified&gt;
      "2010-05-29T14:17:39+02:00"^^http://www.w3.org/2001/XMLSchema#dateTime .
&lt;http://example.org/articles/8&gt; 
   &lt;http://purl.org/dc/terms/modified&gt;
"2010-05-30T09:21:28-04:00"^^http://www.w3.org/2001/XMLSchema#dateTime
.
</pre>
</div>
<div id="blank-nodes" class="section">
<h3>
<span class="secno">
<del class="diff-old">5.9
</del>
<ins class="diff-chg">4.9
</ins>
</span>
Blank
Nodes
</h3>
<p>
At
times,
it
becomes
necessary
to
be
able
to
express
information
without
being
able
to
specify
the
subject.
Typically,
this
is
where
blank
nodes
come
into
play.
In
JSON-LD,
blank
node
identifiers
are
automatically
created
if
a
subject
is
not
specified
using
the
<code>
@
</code>
keyword.
However,
authors
may
name
blank
nodes
by
using
the
special
<code>
_
</code>
CURIE
prefix.
</p>
<pre class="example">
{
...
  "@": "<span class="diff">_:foo</span>",
...
}
</pre>
<p>
The
example
above
would
set
the
subject
to
<code>
_:foo
</code>,
which
can
then
be
used
later
on
in
the
JSON-LD
markup
to
refer
back
to
the
named
blank
node.
</p>
</div>
</div>
<div id="advanced-features" class="section">
<h2>
<span class="secno">
<del class="diff-old">6.
</del>
<ins class="diff-chg">5.
</ins>
</span>
Advanced
Features
</h2>
<p>
JSON-LD
has
a
number
of
features
that
provide
functionality
above
and
beyond
the
core
functionality
provided
by
RDF.
The
following
sections
outline
the
features
that
are
specific
to
JSON-LD.
</p>
<div id="automatic-typing" class="section">
<h3>
<span class="secno">
<del class="diff-old">6.1
</del>
<ins class="diff-chg">5.1
</ins>
</span>
Automatic
Typing
</h3>
<p>
Since
JSON
is
capable
of
expressing
typed
information
such
as
doubles,
integers,
and
boolean
values.
As
demonstrated
below,
JSON-LD
utilizes
that
information
to
create
<del class="diff-old">Typed
Literals
:
</del>
<a class="tref internalDFN" title="typed_literal" href="#dfn-typed_literal">
<ins class="diff-chg">typed
literal
</ins></a><ins class="diff-chg">
s:
</ins>
</p>
<pre class="example">
{
...
  // The following two values are automatically converted to a type of xsd:double
  // and both values are equivalent to each other.
  "measure:cups": <span class="diff">5.3</span>,
  "measure:cups": <span class="diff">5.3e0</span>,
  // The following value is automatically converted to a type of xsd:double as well
  "space:astronomicUnits": <span class="diff">6.5e73</span>,
  // The following value should never be converted to a language-native type
  "measure:stones": <span class="diff">{ "@literal": "4.8", "@datatype": "xsd:decimal" }</span>,
  // This value is automatically converted to having a type of xsd:integer
  "chem:protons": <span class="diff">12</span>,
  // This value is automatically converted to having a type of xsd:boolean
  "sensor:active": <span class="diff">true</span>,
...
}
</pre>
<p class="note">
When
dealing
with
a
number
of
modern
programming
languages,
including
JavaScript
ECMA-262,
there
is
no
distinction
between
<strong>
xsd:decimal
</strong>
and
<strong>
xsd:double
</strong>
values.
That
is,
the
number
<code>
5.3
</code>
and
the
number
<code>
5.3e0
</code>
are
treated
as
if
they
were
the
same.
When
converting
from
JSON-LD
to
a
language-native
format
and
back,
datatype
information
is
lost
in
a
number
of
these
languages.
Thus,
one
could
say
that
<code>
5.3
</code>
is
a
<strong>
xsd:decimal
</strong>
and
<code>
5.3e0
</code>
is
an
<strong>
xsd:double
</strong>
in
JSON-LD,
but
when
both
values
are
converted
to
a
language-native
format
the
datatype
difference
between
the
two
is
lost
because
the
machine-level
representation
will
almost
always
be
a
<strong>
double
</strong>.
Implementers
should
be
aware
of
this
potential
round-tripping
issue
between
<strong>
xsd:decimal
</strong>
and
<strong>
xsd:double
</strong>.
Specifically
objects
with
a
datatype
of
<strong>
xsd:decimal
</strong>
<em class="rfc2119" title="must not">
must
not
</em>
be
converted
to
a
language
native
type.
</p>
</div>
<div id="type-coercion" class="section">
<h3>
<span class="secno">
<del class="diff-old">6.2
</del>
<ins class="diff-chg">5.2
</ins>
</span>
Type
Coercion
</h3>
<p>
JSON-LD
supports
the
coercion
of
types
to
ensure
that
the
zero-edit
goal
of
JSON-LD
can
be
accomplished.
Type
coercion
allows
someone
deploying
JSON-LD
to
coerce
and
incoming
or
outgoing
types
to
the
proper
RDF
type
based
on
a
mapping
of
type
IRIs
to
RDF
types.
Using
type
conversion,
one
may
convert
simple
JSON
data
to
properly
typed
RDF
data.
</p>
<p>
The
example
below
demonstrates
how
a
JSON-LD
author
can
coerce
values
to
<a class="tref internalDFN" title="plain_literal" href="#dfn-plain_literal">
plain
<del class="diff-old">literals,
</del>
<ins class="diff-chg">literal
</ins></a><ins class="diff-chg">
s,
</ins><a class="tref internalDFN" title="typed_literal" href="#dfn-typed_literal">
typed
<del class="diff-old">literals
</del>
<ins class="diff-chg">literal
</ins></a><ins class="diff-chg">
s
</ins>
and
IRIs.
</p>
<pre class="example">
{
  "@context": 
  {  
     "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
     "xsd": "http://www.w3.org/2001/XMLSchema#",
     "name": "http://xmlns.com/foaf/0.1/name",
     "age": "http://xmlns.com/foaf/0.1/age",
     "homepage": "http://xmlns.com/foaf/0.1/homepage",
<del class="diff-old">     "@type":
</del>
<span class="diff">     "@coerce":
     {
        "xsd:integer": "age",
        "xsd:anyURI": "homepage",
     }</span>
  },
  "name": "John Smith",
  "age": <span class="diff">"41"</span>,
  "homepage": <span class="diff">"http://example.org/home/"</span>
}
</pre>
<p>
The
example
above
would
generate
the
following
triples:
</p>
<pre class="example">
_:bnode1
   &lt;http://xmlns.com/foaf/0.1/name&gt;
      "John Smith" .
_:bnode1
   &lt;http://xmlns.com/foaf/0.1/age&gt;
      "41"^^http://www.w3.org/2001/XMLSchema#integer .
_:bnode1
   &lt;http://xmlns.com/foaf/0.1/homepage&gt;
&lt;http://example.org/home/&gt;
.
</pre>
</div>
</div>
<div id="the-json-ld-processing-algorithm" class="section">
<h2>
<span class="secno">
<ins class="diff-chg">6.
</ins></span><ins class="diff-chg">
The
JSON-LD
Processing
Algorithm
</ins></h2><p><ins class="diff-chg">
The
JSON-LD
Processing
Model
describes
processing
rules
for
extracting
RDF
from
a
JSON-LD
document.
Note
that
many
uses
of
JSON-LD
may
not
require
generation
of
RDF.
</ins></p><p><ins class="diff-chg">
The
processing
algorithm
described
in
this
section
is
provided
in
order
to
demonstrate
how
one
might
implement
a
JSON-LD
processor.
Conformant
implementations
are
only
required
to
produce
the
same
type
and
number
of
triples
during
the
output
process
and
are
not
required
to
implement
the
algorithm
exactly
as
described.
</ins></p><p class="issue"><ins class="diff-chg">
The
Processing
Algorithm
is
a
work
in
progress.
</ins></p><div class="informative section" id="overview"><h3><span class="secno"><ins class="diff-chg">
6.1
</ins></span><ins class="diff-chg">
Overview
</ins></h3><p><em><ins class="diff-chg">
This
section
is
non-normative.
</ins></em></p><p><ins class="diff-chg">
JSON-LD
is
intended
to
have
an
easy
to
parse
grammar
that
closely
models
existing
practice
in
using
JSON
for
describing
object
representations.
This
allows
the
use
of
existing
libraries
for
parsing
JSON
in
a
document-oriented
fashion,
or
can
allow
for
stream-based
parsing
similar
to
SAX.
</ins></p><p><ins class="diff-chg">
As
with
other
grammars
used
for
describing
linked
data,
a
key
concept
is
that
of
a
</ins><em><ins class="diff-chg">
resource
</ins></em>.<ins class="diff-chg">
Resources
may
be
of
three
basic
types:
</ins><em><ins class="diff-chg">
IRI
</ins></em><ins class="diff-chg">
s,
for
describing
externally
named
entities,
</ins><em><ins class="diff-chg">
BNodes
</ins></em>,<ins class="diff-chg">
resources
for
which
an
external
name
does
not
exist,
or
is
not
known,
and
Literals,
which
describe
terminal
entities
such
as
strings,
dates
and
other
representations
having
a
lexical
representation
possibly
including
an
explicit
language
or
datatype.
</ins></p><p><ins class="diff-chg">
Data
described
with
JSON-LD
may
be
considered
to
be
the
representation
of
a
graph
made
up
of
</ins><em><ins class="diff-chg">
subject
</ins></em><ins class="diff-chg">
and
</ins><em><ins class="diff-chg">
object
</ins></em><ins class="diff-chg">
resources
related
via
a
</ins><em><ins class="diff-chg">
predicate
</ins></em><ins class="diff-chg">
resource.
However,
specific
implementations
may
choose
to
operate
on
the
document
as
a
normal
JSON
description
of
objects
having
attributes.
</ins></p></div><div id="processing-algorithm-terms" class="section"><h3><span class="secno"><ins class="diff-chg">
6.2
</ins></span><ins class="diff-chg">
Processing
Algorithm
Terms
</ins></h3><dl><dt><dfn title="default_context" id="dfn-default_context"><ins class="diff-chg">
default
context
</ins></dfn></dt><dd><ins class="diff-chg">
a
context
that
is
specified
to
the
JSON-LD
processing
algorithm
before
processing
begins.
</ins></dd><dt><dfn title="default_graph" id="dfn-default_graph"><ins class="diff-chg">
default
graph
</ins></dfn></dt><dd><ins class="diff-chg">
the
destination
graph
for
all
triples
generated
by
JSON-LD
markup.
</ins></dd><dt><dfn title="active_subject" id="dfn-active_subject"><ins class="diff-chg">
active
subject
</ins></dfn></dt><dd><ins class="diff-chg">
the
currently
active
subject
that
the
processor
should
use
when
generating
triples.
</ins></dd><dt><dfn title="active_property" id="dfn-active_property"><ins class="diff-chg">
active
property
</ins></dfn></dt><dd><ins class="diff-chg">
the
currently
active
property
that
the
processor
should
use
when
generating
triples.
</ins></dd><dt><dfn title="active_object" id="dfn-active_object"><ins class="diff-chg">
active
object
</ins></dfn></dt><dd><ins class="diff-chg">
the
currently
active
object
that
the
processor
should
use
when
generating
triples.
</ins></dd><dt><dfn title="active_context" id="dfn-active_context"><ins class="diff-chg">
active
context
</ins></dfn></dt><dd><ins class="diff-chg">
a
context
that
is
used
to
resolve
CURIEs
while
the
processing
algorithm
is
running.
The
</ins><a class="tref internalDFN" title="active_context" href="#dfn-active_context"><ins class="diff-chg">
active
context
</ins></a><ins class="diff-chg">
is
the
context
contained
within
the
</ins><a class="tref internalDFN" title="processor_state" href="#dfn-processor_state"><ins class="diff-chg">
processor
state
</ins></a>.</dd><dt><dfn title="local_context" id="dfn-local_context"><ins class="diff-chg">
local
context
</ins></dfn></dt><dd><ins class="diff-chg">
a
context
that
is
specified
at
the
JSON
associative-array
level,
specified
via
the
</ins><code><ins class="diff-chg">
@context
</ins></code><ins class="diff-chg">
keyword.
</ins></dd><dt><dfn title="processor_state" id="dfn-processor_state"><ins class="diff-chg">
processor
state
</ins></dfn></dt><dd><ins class="diff-chg">
the
</ins><a class="tref internalDFN" title="processor_state" href="#dfn-processor_state"><ins class="diff-chg">
processor
state
</ins></a>,<ins class="diff-chg">
which
includes
the
</ins><a class="tref" title="active__context"><ins class="diff-chg">
active
context
</ins></a>,<a class="tref" title="current_subject"><ins class="diff-chg">
current
subject
</ins></a>,<ins class="diff-chg">
and
</ins><a class="tref" title="current_property"><ins class="diff-chg">
current
property
</ins></a>.<ins class="diff-chg">
The
</ins><a class="tref" title="processor__state"><ins class="diff-chg">
processor
state
</ins></a><ins class="diff-chg">
is
managed
as
a
stack
with
elements
from
the
previous
</ins><a class="tref internalDFN" title="processor_state" href="#dfn-processor_state"><ins class="diff-chg">
processor
state
</ins></a><ins class="diff-chg">
copied
into
a
new
</ins><a class="tref internalDFN" title="processor_state" href="#dfn-processor_state"><ins class="diff-chg">
processor
state
</ins></a><ins class="diff-chg">
when
entering
a
new
associative
array.
</ins></dd></dl></div><div id="processing-tokens-and-keywords" class="section"><h3><span class="secno"><ins class="diff-chg">
6.3
</ins></span><ins class="diff-chg">
Processing
Tokens
and
Keywords
</ins></h3><dl><dt><code><ins class="diff-chg">
@context
</ins></code></dt><dd><ins class="diff-chg">
Used
to
set
the
</ins><a class="tref internalDFN" title="local_context" href="#dfn-local_context"><ins class="diff-chg">
local
context
</ins></a>.</dd><dt><code><ins class="diff-chg">
@base
</ins></code></dt><dd><ins class="diff-chg">
Used
to
set
the
base
IRI
for
all
object
IRIs
affected
by
the
</ins><a class="tref internalDFN" title="active_context" href="#dfn-active_context"><ins class="diff-chg">
active
context
</ins></a>.</dd><dt><code><ins class="diff-chg">
@profile
</ins></code></dt><dd><ins class="diff-chg">
A
reference
to
a
remote
context
description
used
to
set
the
</ins><a class="tref internalDFN" title="local_context" href="#dfn-local_context"><ins class="diff-chg">
local
context
</ins></a>.</dd><dt><code><ins class="diff-chg">
@vocab
</ins></code></dt><dd><ins class="diff-chg">
Used
to
set
the
base
IRI
for
all
property
IRIs
affected
by
the
</ins><a class="tref internalDFN" title="active_context" href="#dfn-active_context"><ins class="diff-chg">
active
context
</ins></a>.</dd><dt><code><ins class="diff-chg">
@coerce
</ins></code></dt><dd><ins class="diff-chg">
Used
to
specify
type
coercion
rules.
</ins></dd><dt><code><ins class="diff-chg">
@literal
</ins></code></dt><dd><ins class="diff-chg">
Used
to
specify
a
literal
value.
</ins></dd><dt><code><ins class="diff-chg">
@iri
</ins></code></dt><dd><ins class="diff-chg">
Used
to
specify
an
IRI
value.
</ins></dd><dt><code><ins class="diff-chg">
@language
</ins></code></dt><dd><ins class="diff-chg">
Used
to
specify
the
language
for
a
literal.
</ins></dd><dt><code><ins class="diff-chg">
@datatype
</ins></code></dt><dd><ins class="diff-chg">
Used
to
specify
the
datatype
for
a
literal.
</ins></dd><dt><code>:</code></dt><dd><ins class="diff-chg">
The
separator
for
CURIEs
when
used
in
JSON
keys
or
JSON
values.
</ins></dd><dt><code><ins class="diff-chg">
@
</ins></code></dt><dd><ins class="diff-chg">
Sets
the
active
subjects.
</ins></dd><dt><code><ins class="diff-chg">
a
</ins></code></dt><dd><ins class="diff-chg">
Used
to
set
the
rdf:type
of
the
active
subjects.
This
token
may
be
conferred
as
syntactic
sugar
for
rdf:type.
</ins></dd></dl><p class="issue"><ins class="diff-chg">
Use
</ins><code><ins class="diff-chg">
@source
</ins></code><ins class="diff-chg">
instead
of
</ins><code><ins class="diff-chg">
@
</ins></code><ins class="diff-chg">
?
</ins></p><p class="issue"><ins class="diff-chg">
Use
</ins><code><ins class="diff-chg">
@type
</ins></code><ins class="diff-chg">
instead
of
</ins><code><ins class="diff-chg">
a
</ins></code><ins class="diff-chg">
?
Note
that
both
are
just
semantic
sugar
for
</ins><code><ins class="diff-chg">
rdf:type
</ins></code>.</p></div><div id="context" class="section"><h3><span class="secno"><ins class="diff-chg">
6.4
</ins></span><ins class="diff-chg">
Context
</ins></h3><p><ins class="diff-chg">
Processing
of
JSON-LD
is
managed
recursively
using
a
process
described
in
</ins><a href="sequence"><ins class="diff-chg">
Sequence
</ins></a>.<ins class="diff-chg">
During
processing,
each
rule
is
applied
using
information
provided
by
the
</ins><a class="tref internalDFN" title="active_context" href="#dfn-active_context"><ins class="diff-chg">
active
context
</ins></a>.<ins class="diff-chg">
Processing
begins
by
pushing
a
new
</ins><a class="tref internalDFN" title="processor_state" href="#dfn-processor_state"><ins class="diff-chg">
processor
state
</ins></a><ins class="diff-chg">
onto
the
</ins><a class="tref internalDFN" title="processor_state" href="#dfn-processor_state"><ins class="diff-chg">
processor
state
</ins></a><ins class="diff-chg">
stack
and
initializing
the
</ins><a class="tref internalDFN" title="active_context" href="#dfn-active_context"><ins class="diff-chg">
active
context
</ins></a><ins class="diff-chg">
with
the
</ins><a class="tref internalDFN" title="default_context" href="#dfn-default_context-1"><ins class="diff-chg">
default
context
</ins></a>.<ins class="diff-chg">
If
a
</ins><a class="tref internalDFN" title="local_context" href="#dfn-local_context"><ins class="diff-chg">
local
context
</ins></a><ins class="diff-chg">
is
encountered,
information
from
the
</ins><a class="tref internalDFN" title="local_context" href="#dfn-local_context"><ins class="diff-chg">
local
context
</ins></a><ins class="diff-chg">
is
merged
into
the
</ins><a class="tref internalDFN" title="active_context" href="#dfn-active_context"><ins class="diff-chg">
active
context
</ins></a>.</p><p class="issue"><ins class="diff-chg">
Should
the
document
URL
be
used
as
the
default
for
</ins><code><ins class="diff-chg">
@base
</ins></code><ins class="diff-chg">
in
the
</ins><a class="tref internalDFN" title="default_context" href="#dfn-default_context-1"><ins class="diff-chg">
default
context
</ins></a><ins class="diff-chg">
?
</ins></p><p><ins class="diff-chg">
The
</ins><a class="tref internalDFN" title="active_context" href="#dfn-active_context"><ins class="diff-chg">
active
context
</ins></a><ins class="diff-chg">
is
used
for
expanding
keys
and
values
of
an
associative
array
(or
elements
of
a
list
(see
</ins><span a="#list-processing"><ins class="diff-chg">
List
Processing
</ins></span><ins class="diff-chg">
)).
</ins></p><p><ins class="diff-chg">
A
</ins><a class="tref internalDFN" title="local_context" href="#dfn-local_context"><ins class="diff-chg">
local
context
</ins></a><ins class="diff-chg">
is
identified
within
an
associative
array
having
a
key
of
</ins><code><ins class="diff-chg">
@context
</ins></code><ins class="diff-chg">
with
an
associative
array
value.
When
processing
a
</ins><a class="tref internalDFN" title="local_context" href="#dfn-local_context"><ins class="diff-chg">
local
context
</ins></a>,<ins class="diff-chg">
special
rules
apply:
</ins></p><ul><li><ins class="diff-chg">
The
key
</ins><code><ins class="diff-chg">
@base
</ins></code><em class="rfc2119" title="must"><ins class="diff-chg">
must
</ins></em><ins class="diff-chg">
have
a
value
of
a
simple
string
with
the
lexical
form
of
IRI
and
is
saved
in
the
</ins><a class="tref internalDFN" title="active_context" href="#dfn-active_context"><ins class="diff-chg">
active
context
</ins></a><ins class="diff-chg">
to
perform
term
mapping
as
described
in
</ins><a href="#iri-processing"><ins class="diff-chg">
IRI
Processing
</ins></a>.</li><li><ins class="diff-chg">
The
key
</ins><code><ins class="diff-chg">
@vocab
</ins></code><em class="rfc2119" title="must"><ins class="diff-chg">
must
</ins></em><ins class="diff-chg">
have
a
value
of
a
simple
string
with
the
lexical
form
of
IRI
and
is
saved
in
the
</ins><a class="tref internalDFN" title="active_context" href="#dfn-active_context"><ins class="diff-chg">
active
context
</ins></a><ins class="diff-chg">
to
perform
term
mapping
as
described
in
</ins><a href="#iri-processing"><ins class="diff-chg">
IRI
Processing
</ins></a>.</li><li><ins class="diff-chg">
The
key
</ins><code><ins class="diff-chg">
@coerce
</ins></code><em class="rfc2119" title="must"><ins class="diff-chg">
must
</ins></em><ins class="diff-chg">
have
a
value
of
an
associative
array.
Processing
of
the
associative
array
is
described
</ins><a href="#coerce"><ins class="diff-chg">
below
</ins></a></li><li><ins class="diff-chg">
Otherwise,
the
key
</ins><em class="rfc2119" title="must"><ins class="diff-chg">
must
</ins></em><ins class="diff-chg">
have
the
lexical
form
of
</ins><cite><a href="http://www.w3.org/TR/2009/REC-xml-names-20091208/#NT-NCName"><ins class="diff-chg">
NCName
</ins></a></cite><ins class="diff-chg">
and
</ins><em class="rfc2119" title="must"><ins class="diff-chg">
must
</ins></em><ins class="diff-chg">
have
the
value
of
a
simple
string
with
the
lexical
form
of
IRI.
Merge
each
key-value
pair
into
the
</ins><a class="tref internalDFN" title="active_context" href="#dfn-active_context"><ins class="diff-chg">
active
context
</ins></a>,<ins class="diff-chg">
overwriting
any
duplicate
values.
</ins></li></ul><p><ins class="diff-chg">
A
</ins><a class="tref internalDFN" title="local_context" href="#dfn-local_context"><ins class="diff-chg">
local
context
</ins></a><ins class="diff-chg">
may
also
be
loaded
from
an
external
document
using
the
</ins><code><ins class="diff-chg">
@profile
</ins></code><ins class="diff-chg">
key
as
described
in
</ins><a href="#vocabulary-profiles"><ins class="diff-chg">
Vocabulary
Profiles
</ins></a>.</p><div id="coerce" class="section"><h4><span class="secno"><ins class="diff-chg">
6.4.1
</ins></span><ins class="diff-chg">
Coerce
</ins></h4><p><ins class="diff-chg">
Map
each
key-value
pair
in
the
</ins><a class="tref internalDFN" title="local_context" href="#dfn-local_context"><ins class="diff-chg">
local
context
</ins></a><ins class="diff-chg">
's
</ins><code><ins class="diff-chg">
@coerce
</ins></code><ins class="diff-chg">
mapping
into
the
</ins><a class="tref internalDFN" title="active_context" href="#dfn-active_context"><ins class="diff-chg">
active
context
</ins></a><ins class="diff-chg">
's
</ins><code><ins class="diff-chg">
@coerce
</ins></code><ins class="diff-chg">
mapping,
overwriting
any
duplicate
values
in
the
</ins><a class="tref internalDFN" title="active_context" href="#dfn-active_context"><ins class="diff-chg">
active
context
</ins></a><ins class="diff-chg">
's
</ins><code><ins class="diff-chg">
@coerce
</ins></code><ins class="diff-chg">
mapping.
The
</ins><code><ins class="diff-chg">
@coerce
</ins></code><ins class="diff-chg">
mapping
has
a
either
of
a
single
CURIE
or
of
an
array
of
CURIEs.
When
merging
with
an
existing
mapping
in
the
</ins><a class="tref internalDFN" title="active_context" href="#dfn-active_context"><ins class="diff-chg">
active
context
</ins></a>,<ins class="diff-chg">
map
all
CURIE
values
to
array
form
and
replace
with
the
union
of
the
value
from
the
</ins><a class="tref internalDFN" title="local_context" href="#dfn-local_context"><ins class="diff-chg">
local
context
</ins></a><ins class="diff-chg">
and
the
value
of
the
</ins><a class="tref internalDFN" title="active_context" href="#dfn-active_context"><ins class="diff-chg">
active
context
</ins></a>.<ins class="diff-chg">
If
the
result
is
an
array
with
a
single
CURIE,
the
processor
</ins><em class="rfc2119" title="may"><ins class="diff-chg">
may
</ins></em><ins class="diff-chg">
represent
this
as
a
string
value.
</ins></p></div></div><div id="chaining" class="section"><h3><span class="secno"><ins class="diff-chg">
6.5
</ins></span><ins class="diff-chg">
Chaining
</ins></h3><p><ins class="diff-chg">
Object
</ins><dfn title="chaining" id="dfn-chaining"><ins class="diff-chg">
chaining
</ins></dfn><ins class="diff-chg">
is
a
JSON-LD
feature
that
allows
an
author
to
use
the
definition
of
JSON-LD
objects
as
</ins><a class="tref" title="property"><ins class="diff-chg">
property
</ins></a><ins class="diff-chg">
values.
This
is
a
commonly
used
mechanism
for
creating
a
parent-child
relationship
between
objects.
</ins></p><p><ins class="diff-chg">
The
example
shows
an
two
objects
related
by
a
property
from
the
first
object:
</ins></p>  <pre class="example"><ins class="diff-chg">
{
...
  "foaf:name": "Manu Sporny",
  "<span class="diff">foaf:knows</span>": {
    "<span class="diff">a</span>": "<span class="diff">foaf:Person</span>",
    "<span class="diff">foaf:name</span>": "<span class="diff">Gregg Kellogg</span>",
  }
...
}
</ins></pre><p><ins class="diff-chg">
An
object
definition
may
be
used
anyplace
a
value
is
legal
in
JSON-LD.
</ins></p></div><div id="iri-processing" class="section"><h3><span class="secno"><ins class="diff-chg">
6.6
</ins></span><ins class="diff-chg">
IRI
Processing
</ins></h3><p><ins class="diff-chg">
Keys
and
some
values
are
evaluated
to
produce
an
IRI.
This
section
defines
an
algorithm
for
transforming
a
value
representing
an
IRI
into
an
actual
IRI.
</ins></p><p><ins class="diff-chg">
IRIs
may
be
represented
as
an
explicit
string,
or
as
a
CURIE,
as
a
value
relative
to
</ins><code><ins class="diff-chg">
@base
</ins></code><ins class="diff-chg">
or
</ins><code><ins class="diff-chg">
@vocab
</ins></code>.</p><p><ins class="diff-chg">
CURIEs
are
defined
more
formally
in
[
</ins><cite><a class="bibref" rel="biblioentry" href="#bib-RDFA-CORE"><ins class="diff-chg">
RDFA-CORE
</ins></a></cite><ins class="diff-chg">
]
</ins><cite><a href="http://www.w3.org/TR/rdfa-core/#s_curies"><ins class="diff-chg">
section
6
"CURIE
Syntax
Definition"
</ins></a></cite>.<ins class="diff-chg">
Generally,
a
CURIE
is
composed
of
a
</ins><em><ins class="diff-chg">
prefix
</ins></em><ins class="diff-chg">
and
a
</ins><em><ins class="diff-chg">
suffix
</ins></em><ins class="diff-chg">
separated
by
a
':'.
In
JSON-LD,
either
the
prefix
may
be
the
empty
string,
denoting
the
</ins><dfn title="default_prefix" id="dfn-default_prefix"><ins class="diff-chg">
default
prefix
</ins></dfn>.</p><p><ins class="diff-chg">
The
procedure
for
generating
an
IRI
is:
</ins></p><ol class="algorithm"><li><ins class="diff-chg">
Split
the
value
into
a
</ins><em><ins class="diff-chg">
prefix
</ins></em><ins class="diff-chg">
and
</ins><em><ins class="diff-chg">
suffix
</ins></em><ins class="diff-chg">
from
the
first
occurrence
of
':'.
</ins></li><li><ins class="diff-chg">
If
the
prefix
is
a
'_',
generate
a
named
BNode
using
the
suffix
as
the
name.
</ins></li><li><ins class="diff-chg">
If
the
</ins><a class="tref internalDFN" title="active_context" href="#dfn-active_context"><ins class="diff-chg">
active
context
</ins></a><ins class="diff-chg">
contains
a
mapping
for
</ins><em><ins class="diff-chg">
prefix
</ins></em>,<ins class="diff-chg">
generate
an
IRI
by
prepending
the
mapped
prefix
to
the
(possibly
empty)
suffix.
Note
that
an
empty
suffix
and
no
suffix
(meaning
the
value
contains
no
':'
string
at
all)
are
treated
equivalently.
</ins></li><li><ins class="diff-chg">
If
the
IRI
being
processed
is
for
a
property
(i.e.,
a
key
value
in
an
associative
array,
or
a
value
in
a
</ins><code><ins class="diff-chg">
@coerce
</ins></code><ins class="diff-chg">
mapping)
and
the
active
context
has
a
</ins><code><ins class="diff-chg">
@vocab
</ins></code><ins class="diff-chg">
mapping,
join
the
mapped
value
to
the
suffix
using
the
method
described
in
[
</ins><cite><a class="bibref" rel="biblioentry" href="#bib-RFC3987"><ins class="diff-chg">
RFC3987
</ins></a></cite><ins class="diff-chg">
].
</ins></li><li><ins class="diff-chg">
If
the
IRI
being
processed
is
for
a
subject
or
object
(i.e.,
not
a
property)
and
the
active
context
has
a
</ins><code><ins class="diff-chg">
@base
</ins></code><ins class="diff-chg">
mapping,
join
the
mapped
value
to
the
suffix
using
the
method
described
in
[
</ins><cite><a class="bibref" rel="biblioentry" href="#bib-RFC3987"><ins class="diff-chg">
RFC3987
</ins></a></cite><ins class="diff-chg">
].
</ins></li><li><ins class="diff-chg">
Otherwise,
use
the
value
directly
as
an
IRI.
</ins></li></ol><p></p></div></div><div id="sequence" class="section">
<h2>
<span class="secno">
7.
</span>
<ins class="diff-new">Sequence
</ins></h2><p><ins class="diff-new">
The
algorithm
below
is
designed
for
in-memory
implementations
with
random
access
to
associative
array
elements.
For
a
description
of
a
streaming
implementation,
see
</ins><a href="streaming-processors"><ins class="diff-new">
Appendix
B
</ins></a>.</p><p><ins class="diff-new">
A
conforming
JSON-LD
processor
</ins><em class="rfc2119" title="must"><ins class="diff-new">
must
</ins></em><ins class="diff-new">
implement
a
processing
algorithm
that
results
in
the
same
</ins><a class="tref internalDFN" title="default_graph" href="#dfn-default_graph"><ins class="diff-new">
default
graph
</ins></a><ins class="diff-new">
that
the
following
algorithm
generates:
</ins></p><ol class="algorithm"><li id="processing-step-default-context"><ins class="diff-new">
Create
a
new
</ins><a class="tref internalDFN" title="processor_state" href="#dfn-processor_state"><ins class="diff-new">
processor
state
</ins></a><ins class="diff-new">
with
with
the
</ins><a class="tref internalDFN" title="active_context" href="#dfn-active_context"><ins class="diff-new">
active
context
</ins></a><ins class="diff-new">
set
to
the
</ins><a class="tref internalDFN" title="default_context" href="#dfn-default_context-1"><ins class="diff-new">
default
context
</ins></a><ins class="diff-new">
and
</ins><a class="tref internalDFN" title="active_subject" href="#dfn-active_subject"><ins class="diff-new">
active
subject
</ins></a><ins class="diff-new">
and
</ins><a class="tref internalDFN" title="active_property" href="#dfn-active_property"><ins class="diff-new">
active
property
</ins></a><ins class="diff-new">
initialized
to
NULL.
</ins></li><li id="processing-step-associative"><ins class="diff-new">
If
an
associative
array
is
detected,
perform
the
following
steps:
</ins><ol class="algorithm"><li><ins class="diff-new">
If
the
associative
array
has
a
</ins><code><ins class="diff-new">
@context
</ins></code><ins class="diff-new">
key,
process
the
local
context
as
described
in
</ins><a href="context"><ins class="diff-new">
Context
</ins></a>.</li><li><ins class="diff-new">
If
the
associative
array
has
an
</ins><code><ins class="diff-new">
@iri
</ins></code><ins class="diff-new">
key,
set
the
</ins><a class="tref internalDFN" title="active_object" href="#dfn-active_object"><ins class="diff-new">
active
object
</ins></a><ins class="diff-new">
by
performing
</ins><a href="#iri-processing"><ins class="diff-new">
IRI
Processing
</ins></a><ins class="diff-new">
on
the
associated
value.
Generate
a
triple
representing
the
</ins><a class="tref internalDFN" title="active_subject" href="#dfn-active_subject"><ins class="diff-new">
active
subject
</ins></a>,<ins class="diff-new">
the
</ins><a class="tref internalDFN" title="active_property" href="#dfn-active_property"><ins class="diff-new">
active
property
</ins></a><ins class="diff-new">
and
the
</ins><a class="tref internalDFN" title="active_object" href="#dfn-active_object"><ins class="diff-new">
active
object
</ins></a>.<ins class="diff-new">
Return
the
</ins><a class="tref internalDFN" title="active_object" href="#dfn-active_object"><ins class="diff-new">
active
object
</ins></a><ins class="diff-new">
to
the
calling
location.
</ins></li><li><ins class="diff-new">
If
the
associative
array
has
a
</ins><code><ins class="diff-new">
@literal
</ins></code><ins class="diff-new">
key,
set
the
</ins><a class="tref internalDFN" title="active_object" href="#dfn-active_object"><ins class="diff-new">
active
object
</ins></a><ins class="diff-new">
to
a
literal
value
as
follows:
</ins><ul><li><ins class="diff-new">
as
a
</ins><a class="tref internalDFN" title="typed_literal" href="#dfn-typed_literal"><ins class="diff-new">
typed
literal
</ins></a><ins class="diff-new">
if
the
associative
array
contains
a
</ins><code><ins class="diff-new">
@datatype
</ins></code><ins class="diff-new">
key
after
performing
</ins><a href="#iri-processing"><ins class="diff-new">
IRI
Processing
</ins></a><ins class="diff-new">
on
the
specified
</ins><code><ins class="diff-new">
@datatype
</ins></code>.</li><li><ins class="diff-new">
otherwise,
as
a
</ins><a class="tref internalDFN" title="plain_literal" href="#dfn-plain_literal"><ins class="diff-new">
plain
literal
</ins></a>.<ins class="diff-new">
If
the
associative
array
contains
a
</ins><code><ins class="diff-new">
@language
</ins></code><ins class="diff-new">
key,
use
it's
value
to
set
the
language
of
the
plain
literal.
</ins></li></ul><ins class="diff-new">
Generate
a
triple
representing
the
</ins><a class="tref internalDFN" title="active_subject" href="#dfn-active_subject"><ins class="diff-new">
active
subject
</ins></a>,<ins class="diff-new">
the
</ins><a class="tref" title="active__property"><ins class="diff-new">
active
property
</ins></a><ins class="diff-new">
and
the
</ins><a class="tref internalDFN" title="active_object" href="#dfn-active_object"><ins class="diff-new">
active
object
</ins></a>.<ins class="diff-new">
Return
the
</ins><a class="tref internalDFN" title="active_object" href="#dfn-active_object"><ins class="diff-new">
active
object
</ins></a><ins class="diff-new">
to
the
calling
location.
</ins></li><li><ins class="diff-new">
If
the
associative
array
has
a
</ins><code><ins class="diff-new">
@
</ins></code><ins class="diff-new">
key:
</ins><ol class="algorithm"><li><ins class="diff-new">
If
the
value
is
a
string,
set
the
</ins><a class="tref internalDFN" title="active_object" href="#dfn-active_object"><ins class="diff-new">
active
object
</ins></a><ins class="diff-new">
to
the
result
of
performing
</ins><a href="#iri-processing"><ins class="diff-new">
IRI
Processing
</ins></a>.<ins class="diff-new">
Generate
a
triple
representing
the
</ins><a class="tref internalDFN" title="active_subject" href="#dfn-active_subject"><ins class="diff-new">
active
subject
</ins></a>,<ins class="diff-new">
the
</ins><a class="tref internalDFN" title="active_property" href="#dfn-active_property"><ins class="diff-new">
active
property
</ins></a><ins class="diff-new">
and
the
</ins><a class="tref internalDFN" title="active_object" href="#dfn-active_object"><ins class="diff-new">
active
object
</ins></a>.<ins class="diff-new">
Set
the
</ins><a class="tref internalDFN" title="active_subject" href="#dfn-active_subject"><ins class="diff-new">
active
subject
</ins></a><ins class="diff-new">
to
the
</ins><a class="tref internalDFN" title="active_object" href="#dfn-active_object"><ins class="diff-new">
active
object
</ins></a>.</li><li><ins class="diff-new">
Create
a
new
</ins><a class="tref internalDFN" title="processor_state" href="#dfn-processor_state"><ins class="diff-new">
processor
state
</ins></a><ins class="diff-new">
using
copies
of
the
</ins><a class="tref internalDFN" title="active_context" href="#dfn-active_context"><ins class="diff-new">
active
context
</ins></a>,<a class="tref internalDFN" title="active_subject" href="#dfn-active_subject"><ins class="diff-new">
active
subject
</ins></a><ins class="diff-new">
and
</ins><a class="tref internalDFN" title="active_property" href="#dfn-active_property"><ins class="diff-new">
active
property
</ins></a><ins class="diff-new">
and
process
the
value
starting
at
</ins><a href="#processing-step-associative"><ins class="diff-new">
Step
2
</ins></a>,<ins class="diff-new">
set
the
</ins><a class="tref" title="active__subject"><ins class="diff-new">
active
subject
</ins></a><ins class="diff-new">
to
the
result
and
proceed
using
the
previous
</ins><a class="tref internalDFN" title="processor_state" href="#dfn-processor_state"><ins class="diff-new">
processor
state
</ins></a>.</li></ol></li><li><ins class="diff-new">
If
the
associative
array
does
not
have
a
</ins><code><ins class="diff-new">
@
</ins></code><ins class="diff-new">
key,
set
the
</ins><a class="tref" title="active__object"><ins class="diff-new">
active
object
</ins></a><ins class="diff-new">
to
newly
generated
</ins><a class="tref" title="blank_node_identifier"><ins class="diff-new">
blank
node
identifier
</ins></a>.<ins class="diff-new">
Generate
a
triple
representing
the
</ins><a class="tref internalDFN" title="active_subject" href="#dfn-active_subject"><ins class="diff-new">
active
subject
</ins></a>,<ins class="diff-new">
the
</ins><a class="tref internalDFN" title="active_property" href="#dfn-active_property"><ins class="diff-new">
active
property
</ins></a><ins class="diff-new">
and
the
</ins><a class="tref internalDFN" title="active_object" href="#dfn-active_object"><ins class="diff-new">
active
object
</ins></a>.<ins class="diff-new">
Set
the
</ins><a class="tref internalDFN" title="active_subject" href="#dfn-active_subject"><ins class="diff-new">
active
subject
</ins></a><ins class="diff-new">
to
the
</ins><a class="tref" title="active__object"><ins class="diff-new">
active
object
</ins></a>.</li><li><ins class="diff-new">
For
each
key
in
the
associative
array
that
has
not
already
been
processed,
perform
the
following
steps:
</ins><ol class="algorithm"><li><ins class="diff-new">
If
the
key
is
</ins><code><ins class="diff-new">
a
</ins></code>,<ins class="diff-new">
set
the
</ins><a class="tref internalDFN" title="active_property" href="#dfn-active_property"><ins class="diff-new">
active
property
</ins></a><ins class="diff-new">
to
</ins><code><ins class="diff-new">
rdf:type
</ins></code>.</li><li><ins class="diff-new">
Otherwise,
set
the
</ins><a class="tref internalDFN" title="active_property" href="#dfn-active_property"><ins class="diff-new">
active
property
</ins></a><ins class="diff-new">
to
the
result
of
performing
</ins><a href="#iri-processing"><ins class="diff-new">
IRI
Processing
</ins></a><ins class="diff-new">
on
the
key.
</ins></li><li><ins class="diff-new">
Create
a
new
</ins><a class="tref internalDFN" title="processor_state" href="#dfn-processor_state"><ins class="diff-new">
processor
state
</ins></a><ins class="diff-new">
copies
of
the
</ins><a class="tref internalDFN" title="active_context" href="#dfn-active_context"><ins class="diff-new">
active
context
</ins></a>,<a class="tref internalDFN" title="active_subject" href="#dfn-active_subject"><ins class="diff-new">
active
subject
</ins></a><ins class="diff-new">
and
</ins><a class="tref internalDFN" title="active_property" href="#dfn-active_property"><ins class="diff-new">
active
property
</ins></a><ins class="diff-new">
and
process
the
value
starting
at
</ins><a href="#processing-step-associative"><ins class="diff-new">
Step
2
</ins></a><ins class="diff-new">
and
proceed
using
the
previous
</ins><a class="tref internalDFN" title="processor_state" href="#dfn-processor_state"><ins class="diff-new">
processor
state
</ins></a>.</li></ol></li><li><ins class="diff-new">
Return
the
</ins><a class="tref internalDFN" title="active_object" href="#dfn-active_object"><ins class="diff-new">
active
object
</ins></a><ins class="diff-new">
to
the
calling
location.
</ins></li></ol></li><li><ins class="diff-new">
If
a
regular
array
is
detected,
process
each
value
in
the
array
by
doing
the
following
returning
the
result
of
processing
the
last
value
in
the
array:
</ins><ol class="algorithm"><li><ins class="diff-new">
If
the
value
is
a
regular
array,
generate
an
RDF
List
by
linking
each
element
of
the
list
using
</ins><code><ins class="diff-new">
rdf:first
</ins></code><ins class="diff-new">
and
</ins><code><ins class="diff-new">
rdf:next
</ins></code>,<ins class="diff-new">
terminating
the
list
with
</ins><code><ins class="diff-new">
rdf:nil
</ins></code><ins class="diff-new">
using
the
following
sequence:
</ins><ol><li><ins class="diff-new">
If
the
list
has
no
element,
generate
a
triple
using
the
</ins><a class="tref internalDFN" title="active_subject" href="#dfn-active_subject"><ins class="diff-new">
active
subject
</ins></a>,<a class="tref internalDFN" title="active_property" href="#dfn-active_property"><ins class="diff-new">
active
property
</ins></a><ins class="diff-new">
and
</ins><code><ins class="diff-new">
rdf:nil
</ins></code>.</li><li><ins class="diff-new">
Otherwise,
generate
a
triple
using
using
the
</ins><a class="tref internalDFN" title="active_subject" href="#dfn-active_subject"><ins class="diff-new">
active
subject
</ins></a>,<a class="tref internalDFN" title="active_property" href="#dfn-active_property"><ins class="diff-new">
active
property
</ins></a><ins class="diff-new">
and
a
newly
generated
BNode
identified
as
</ins><em><ins class="diff-new">
first
bnode
</ins></em>.</li><li><ins class="diff-new">
For
each
element
other
than
the
last
element
in
the
list:
</ins><ol><li><ins class="diff-new">
Create
a
processor
state
using
the
active
context,
</ins><em><ins class="diff-new">
first
bnode
</ins></em><ins class="diff-new">
as
the
</ins><a class="tref internalDFN" title="active_subject" href="#dfn-active_subject"><ins class="diff-new">
active
subject
</ins></a>,<ins class="diff-new">
and
</ins><code><ins class="diff-new">
rdf:first
</ins></code><ins class="diff-new">
as
the
</ins><a class="tref internalDFN" title="active_property" href="#dfn-active_property"><ins class="diff-new">
active
property
</ins></a>.</li><li><ins class="diff-new">
Unless
this
is
the
last
element
in
the
list,
generate
a
new
BNode
identified
as
</ins><em><ins class="diff-new">
rest
bnode
</ins></em>,<ins class="diff-new">
otherwise
use
</ins><code><ins class="diff-new">
rdf:nil
</ins></code>.</li><li><ins class="diff-new">
Generate
a
new
triple
using
</ins><em><ins class="diff-new">
first
bnode
</ins></em>,<code><ins class="diff-new">
rdf:rest
</ins></code><ins class="diff-new">
and
</ins><em><ins class="diff-new">
rest
bnode
</ins></em>.</li><li><ins class="diff-new">
Set
</ins><em><ins class="diff-new">
first
bnode
</ins></em><ins class="diff-new">
to
</ins><em><ins class="diff-new">
rest
bnode
</ins></em>.</li></ol></li></ol></li><li><ins class="diff-new">
Otherwise,
create
a
new
</ins><a class="tref internalDFN" title="processor_state" href="#dfn-processor_state"><ins class="diff-new">
processor
state
</ins></a><ins class="diff-new">
copies
of
the
</ins><a class="tref internalDFN" title="active_context" href="#dfn-active_context"><ins class="diff-new">
active
context
</ins></a>,<a class="tref internalDFN" title="active_subject" href="#dfn-active_subject"><ins class="diff-new">
active
subject
</ins></a><ins class="diff-new">
and
</ins><a class="tref internalDFN" title="active_property" href="#dfn-active_property"><ins class="diff-new">
active
property
</ins></a><ins class="diff-new">
and
process
the
value
starting
at
</ins><a href="#processing-step-associative"><ins class="diff-new">
Step
2
</ins></a><ins class="diff-new">
and
proceed
using
the
previous
</ins><a class="tref internalDFN" title="processor_state" href="#dfn-processor_state"><ins class="diff-new">
processor
state
</ins></a>.</li></ol></li><li><ins class="diff-new">
If
a
string
is
detected,
generate
a
triple
using
the
</ins><a class="tref internalDFN" title="active_subject" href="#dfn-active_subject"><ins class="diff-new">
active
subject
</ins></a>,<a class="tref internalDFN" title="active_object" href="#dfn-active_object"><ins class="diff-new">
active
object
</ins></a><ins class="diff-new">
and
a
</ins><a class="tref internalDFN" title="plain_literal" href="#dfn-plain_literal"><ins class="diff-new">
plain
literal
</ins></a><ins class="diff-new">
value
created
from
the
string.
</ins></li><li><ins class="diff-new">
If
a
number
is
detected,
generate
a
</ins><a class="tref internalDFN" title="typed_literal" href="#dfn-typed_literal"><ins class="diff-new">
typed
literal
</ins></a><ins class="diff-new">
using
a
string
representation
of
the
value
with
datatype
set
to
either
</ins><code><ins class="diff-new">
xsd:integer
</ins></code><ins class="diff-new">
or
</ins><code><ins class="diff-new">
xsd:double
</ins></code>,<ins class="diff-new">
depending
on
if
the
value
contains
a
fractional
and/or
an
exponential
component.
Generate
a
triple
using
the
</ins><a class="tref" title="active__subject"><ins class="diff-new">
active
subject
</ins></a>,<a class="tref internalDFN" title="active_object" href="#dfn-active_object"><ins class="diff-new">
active
object
</ins></a><ins class="diff-new">
and
the
generated
typed
literal.
</ins></li><li><ins class="diff-new">
Otherwise,
if
</ins><strong><ins class="diff-new">
true
</ins></strong><ins class="diff-new">
or
</ins><strong><ins class="diff-new">
false
</ins></strong><ins class="diff-new">
is
detected,
generate
a
triple
using
the
</ins><a class="tref internalDFN" title="active_subject" href="#dfn-active_subject"><ins class="diff-new">
active
subject
</ins></a>,<a class="tref internalDFN" title="active_object" href="#dfn-active_object"><ins class="diff-new">
active
object
</ins></a><ins class="diff-new">
and
a
</ins><a class="tref internalDFN" title="typed_literal" href="#dfn-typed_literal"><ins class="diff-new">
typed
literal
</ins></a><ins class="diff-new">
value
created
from
the
string
representation
of
the
value
with
datatype
set
to
</ins><code><ins class="diff-new">
xsd:boolean
</ins></code>.</li></ol></div><div id="best-practices" class="section"><h2><span class="secno"><ins class="diff-new">
8.
</ins></span>
Best
Practices
</h2>
<p>
The
nature
of
Web
programming
allows
one
to
use
basic
technologies,
such
as
JSON-LD,
across
a
variety
of
systems
and
environments.
This
section
attempts
to
describe
some
of
those
environments
and
the
way
in
which
JSON-LD
can
be
integrated
in
order
to
help
alleviate
certain
development
headaches.
</p>
<div id="javascript" class="section">
<h3>
<span class="secno">
<del class="diff-old">7.1
</del>
<ins class="diff-chg">8.1
</ins>
</span>
JavaScript
</h3>
<p class="issue">
It
is
expected
that
JSON-LD
will
be
used
quite
a
bit
in
JavaScript
environments,
however,
features
like
the
expanded
form
for
object
values
mean
that
using
JSON-LD
directly
in
JavaScript
may
be
annoying
without
a
middleware
layer
such
as
a
simple
library
that
converts
JSON-LD
markup
before
JavaScript
uses
it.
One
could
say
that
JSON-LD
is
a
good
fit
for
the
RDF
API,
which
enables
a
variety
of
RDF-based
Web
Applications,
but
some
don't
want
to
require
that
level
of
functionality
just
to
use
JSON-LD.
The
group
is
still
discussing
the
best
way
to
proceed,
so
input
on
how
JSON-LD
could
more
easily
be
utilized
in
JavaScript
environments
would
be
very
much
appreciated.
</p>
</div>
<div id="schema-less-databases" class="section">
<h3>
<span class="secno">
<del class="diff-old">7.2
</del>
<ins class="diff-chg">8.2
</ins>
</span>
Schema-less
Databases
</h3>
<p class="issue">
Databases
such
as
CouchDB
and
MongoDB
allow
the
creation
of
schema-less
data
stores.
RDF
is
a
type
of
schema-less
data
model
and
thus
lends
itself
to
databases
such
as
CouchDB
and
MongoDB.
Both
of
these
databases
can
use
JSON-LD
as
their
storage
format.
The
group
needs
feedback
from
CouchDB
and
MongoDB
experts
regarding
the
usefulness
of
JSON-LD
in
those
environments.
</p>
<p class="issue">
<ins class="diff-new">MongoDB
does
not
allow
the
'.'
character
to
be
used
in
key
names.
This
prevents
developers
from
storing
IRIs
as
keys,
which
also
prevents
storage
of
the
data
in
normalized
form.
While
this
issue
can
be
avoided
by
using
CURIEs
for
key
values,
it
is
not
known
if
this
mechanism
is
enough
to
allow
JSON-LD
to
be
used
in
MongoDB
in
a
way
that
is
useful
to
developers.
</ins></p>
</div>
</div>
<div id="advanced-concepts" class="section">
<h2>
<span class="secno">
<del class="diff-old">8.
</del>
<ins class="diff-chg">9.
</ins>
</span>
Advanced
Concepts
</h2>
<p class="issue">
There
are
a
few
advanced
concepts
where
it
is
not
clear
whether
or
not
the
JSON-LD
specification
is
going
to
support
the
complexity
necessary
to
support
each
concept.
The
entire
section
on
Advanced
Concepts
should
be
considered
as
discussion
points;
it
is
merely
a
list
of
possibilities
where
all
of
the
benefits
and
drawbacks
have
not
been
explored.
</p>
<div id="vocabulary-profiles" class="section">
<h3>
<span class="secno">
<del class="diff-old">8.1
</del>
<ins class="diff-chg">9.1
</ins>
</span>
Vocabulary
Profiles
</h3>
<p>
One
of
the
more
powerful
features
of
RDFa
1.1
Core
is
the
ability
to
specify
a
collection
of
prefixes
and
terms
that
can
be
re-used
by
a
processor
to
simplfy
markup.
JSON-LD
provides
a
similar
mechanism
called
Vocabulary
Profiles,
which
is
the
inclusion
of
a
context
external
to
the
JSON-LD
document.
</p>
<p>
The
example
below
demonstrates
how
one
may
specify
an
external
Vocabulary
Profile.
Assume
the
following
profile
exists
at
this
imaginary
URL:
<code>
http://example.org/profiles/contacts
</code>.
</p>
<pre class="example">
{
  "@context": 
  {
     "xsd": "http://www.w3.org/2001/XMLSchema#",
     "name": "http://xmlns.com/foaf/0.1/name",
     "age": "http://xmlns.com/foaf/0.1/age",
     "homepage": "http://xmlns.com/foaf/0.1/homepage",
     "#types":
     {
        "age": "xsd:integer",
        "homepage": "xsd:anyURI",
     }
  }
}
</pre>
<p>
The
profile
listed
above
can
be
used
in
the
following
way:
</p>
<pre class="example">
{
  "@profile": "http://example.org/profiles/contacts",
  "name": "John Smith",
  "age": "41",
  "homepage": "http://example.org/home/"
}
</pre>
<p>
The
example
above
would
generate
the
following
triples:
</p>
<pre class="example">
_:bnode1
   &lt;http://xmlns.com/foaf/0.1/name&gt;
      "John Smith" .
_:bnode1
   &lt;http://xmlns.com/foaf/0.1/age&gt;
      "41"^^http://www.w3.org/2001/XMLSchema#integer .
_:bnode1
   &lt;http://xmlns.com/foaf/0.1/homepage&gt;
&lt;http://example.org/home/&gt;
.
</pre>
</div>
<div id="disjoint-graphs" class="section">
<h3>
<span class="secno">
<del class="diff-old">8.2
</del>
<ins class="diff-chg">9.2
</ins>
</span>
Disjoint
Graphs
</h3>
<p>
When
serializing
an
RDF
graph
that
contains
two
or
more
sections
of
the
graph
which
are
entirely
disjoint,
one
must
use
an
array
to
express
the
graph
as
two
graphs.
This
may
not
be
acceptable
to
some
authors,
who
would
rather
express
the
information
as
one
graph.
Since,
by
definition,
disjoint
graphs
require
there
to
be
two
top-level
objects,
JSON-LD
utilizes
a
mechanism
that
allows
disjoint
graphs
to
be
expressed
using
a
single
graph.
</p>
<p>
Assume
the
following
RDF
graph:
</p>
<pre class="example">
&lt;http://example.org/people#john&gt; 
   &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#type&gt;
      &lt;http://xmlns.com/foaf/0.1/Person&gt; .
&lt;http://example.org/people#jane&gt; 
   &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#type&gt;
&lt;http://xmlns.com/foaf/0.1/Person&gt;
.
</pre>
<p>
Since
the
two
subjects
are
entirely
disjoint
with
one
another,
it
is
impossible
to
express
the
RDF
graph
above
using
a
single
JSON-LD
associative
array.
</p>
<p>
In
JSON-LD,
one
can
use
the
subject
to
express
disjoint
graphs
as
a
single
graph:
</p>
<pre class="example">
{
  "@": 
  [
    {
      "@": "http://example.org/people#john",
      "a": "foaf:Person"
    },
    {
      "@": "http://example.org/people#jane",
      "a": "foaf:Person"
    }
  ]
}
</pre>
<p>
A
disjoint
graph
could
also
be
expressed
like
so:
</p>
<pre class="example">
[
  {
    "@": "http://example.org/people#john",
    "a": "foaf:Person"
  },
  {
    "@": "http://example.org/people#jane",
    "a": "foaf:Person"
  }
]
</pre>
</div>
<div id="the-json-ld-api" class="section">
<h3>
<span class="secno">
<del class="diff-old">8.3
</del>
<ins class="diff-chg">9.3
</ins>
</span>
The
JSON-LD
API
</h3>
<p>
This
API
provides
a
clean
mechanism
that
enables
developers
to
convert
JSON-LD
data
into
a
format
that
is
easier
to
work
with
in
various
programming
languages.
</p>
<pre class="idl">
<span class="idlInterface" id="idl-def-JSONLDProcessor">[<span class="extAttr">NoInterfaceObject</span>]
interface <span class="idlInterfaceID">JSONLDProcessor</span> {
<span class="idlMethod">    <span class="idlMethType"><a>object</a></span> <span class="idlMethName"><a href="#widl-JSONLDProcessor-toProjection-object-DOMString-jsonld-object-template-DOMString-subject-JSONLDParserCallback-callback">toProjection</a></span> (<span class="idlParam">in <span class="idlParamType"><a>DOMString</a></span> <span class="idlParamName">jsonld</span></span>, <span class="idlParam">in <span class="idlParamType"><a>object</a>?</span> <span class="idlParamName">template</span></span>, <span class="idlParam">in <span class="idlParamType"><a>DOMString</a>?</span> <span class="idlParamName">subject</span></span>, <span class="idlParam">in optional <span class="idlParamType"><a>JSONLDParserCallback</a>?</span> <span class="idlParamName">callback</span></span>);</span>
<span class="idlMethod">    <span class="idlMethType"><a>Graph</a></span>  <span class="idlMethName"><a href="#widl-JSONLDProcessor-toGraph-Graph-DOMString-jsonld-JSONLDParserCallback-callback">toGraph</a></span> (<span class="idlParam">in <span class="idlParamType"><a>DOMString</a></span> <span class="idlParamName">jsonld</span></span>, <span class="idlParam">in optional <span class="idlParamType"><a>JSONLDParserCallback</a>?</span> <span class="idlParamName">callback</span></span>);</span>
};</span>
</pre>
<div id="methods" class="section">
<h4>
<span class="secno">
<del class="diff-old">8.3.1
</del>
<ins class="diff-chg">9.3.1
</ins>
</span>
Methods
</h4>
<dl class="methods">
<dt id="widl-JSONLDProcessor-toGraph-Graph-DOMString-jsonld-JSONLDParserCallback-callback">
<code>
toGraph
</code>
</dt>
<dd>
Parses
JSON-LD
and
transforms
the
data
into
an
Graph,
which
is
compatible
with
the
RDF
Interfaces
API
specification
[
<cite>
<a class="bibref" rel="biblioentry" href="#bib-RDF-INTERFACES">
RDF-INTERFACES
</a>
</cite>
].
This
method
will
return
<code>
null
</code>
if
there
are
any
errors,
or
if
the
RDF
Interfaces
API
is
not
available
for
use.
<table class="parameters">
<tr>
<th>
Parameter
</th>
<th>
Type
</th>
<th>
Nullable
</th>
<th>
Optional
</th>
<th>
Description
</th>
</tr>
<tr>
<td class="prmName">
jsonld
</td>
<td class="prmType">
<code>
<a>
DOMString
</a>
</code>
</td>
<td class="prmNullFalse">
✘
</td>
<td class="prmOptFalse">
✘
</td>
<td class="prmDesc">
The
JSON-LD
string
to
parse
into
the
RDFGraph.
</td>
</tr>
<tr>
<td class="prmName">
callback
</td>
<td class="prmType">
<code>
<a>
JSONLDParserCallback
</a>
</code>
</td>
<td class="prmNullTrue">
✔
</td>
<td class="prmOptTrue">
✔
</td>
<td class="prmDesc">
A
callback
that
is
called
whenever
a
processing
error
occurs
on
the
given
JSON-LD
string.
</td>
</tr>
</table>
<div>
<em>
No
exceptions.
</em>
</div>
<div>
<em>
Return
type:
</em>
<code>
<a>
Graph
</a>
</code>
</div>
</dd>
<dt id="widl-JSONLDProcessor-toProjection-object-DOMString-jsonld-object-template-DOMString-subject-JSONLDParserCallback-callback">
<code>
toProjection
</code>
</dt>
<dd>
Parses
JSON-LD
text
into
an
RDF
API
Projection
object
as
specified
by
the
RDF
API
specification
[
<cite>
<a class="bibref" rel="biblioentry" href="#bib-RDF-API">
RDF-API
</a>
</cite>
].
If
there
are
any
errors,
<code>
null
</code>
is
returned.
<table class="parameters">
<tr>
<th>
Parameter
</th>
<th>
Type
</th>
<th>
Nullable
</th>
<th>
Optional
</th>
<th>
Description
</th>
</tr>
<tr>
<td class="prmName">
jsonld
</td>
<td class="prmType">
<code>
<a>
DOMString
</a>
</code>
</td>
<td class="prmNullFalse">
✘
</td>
<td class="prmOptFalse">
✘
</td>
<td class="prmDesc">
The
JSON-LD
string
to
parse
into
the
Projection.
</td>
</tr>
<tr>
<td class="prmName">
template
</td>
<td class="prmType">
<code>
<a>
object
</a>
</code>
</td>
<td class="prmNullTrue">
✔
</td>
<td class="prmOptFalse">
✘
</td>
<td class="prmDesc">
The
Projection
template
to
use
when
building
the
Projection.
</td>
</tr>
<tr>
<td class="prmName">
subject
</td>
<td class="prmType">
<code>
<a>
DOMString
</a>
</code>
</td>
<td class="prmNullTrue">
✔
</td>
<td class="prmOptFalse">
✘
</td>
<td class="prmDesc">
The
subject
to
use
when
building
the
Projection.
</td>
</tr>
<tr>
<td class="prmName">
callback
</td>
<td class="prmType">
<code>
<a>
JSONLDParserCallback
</a>
</code>
</td>
<td class="prmNullTrue">
✔
</td>
<td class="prmOptTrue">
✔
</td>
<td class="prmDesc">
A
callback
that
is
called
whenever
a
processing
error
occurs
on
the
given
JSON-LD
string.
</td>
</tr>
</table>
<div>
<em>
No
exceptions.
</em>
</div>
<div>
<em>
Return
type:
</em>
<code>
<a>
object
</a>
</code>
</div>
</dd>
</dl>
</div>
<p>
The
JSONLDParserCallback
is
called
whenever
a
processing
error
occurs
on
input
data.
</p>
<pre class="idl">
<span class="idlInterface" id="idl-def-JSONLDProcessorCallback">[<span class="extAttr">NoInterfaceObject Callback</span>]
interface <span class="idlInterfaceID">JSONLDProcessorCallback</span> {
<span class="idlMethod">    <span class="idlMethType"><a>void</a></span> <span class="idlMethName"><a href="#widl-JSONLDProcessorCallback-error-void-DOMString-error">error</a></span> (<span class="idlParam">in <span class="idlParamType"><a>DOMString</a></span> <span class="idlParamName">error</span></span>);</span>
};</span>
</pre>
<div id="methods-1" class="section">
<h4>
<span class="secno">
<del class="diff-old">8.3.2
</del>
<ins class="diff-chg">9.3.2
</ins>
</span>
Methods
</h4>
<dl class="methods">
<dt id="widl-JSONLDProcessorCallback-error-void-DOMString-error">
<code>
error
</code>
</dt>
<dd>
This
callback
is
invoked
whenever
an
error
occurs
during
processing.
<table class="parameters">
<tr>
<th>
Parameter
</th>
<th>
Type
</th>
<th>
Nullable
</th>
<th>
Optional
</th>
<th>
Description
</th>
</tr>
<tr>
<td class="prmName">
error
</td>
<td class="prmType">
<code>
<a>
DOMString
</a>
</code>
</td>
<td class="prmNullFalse">
✘
</td>
<td class="prmOptFalse">
✘
</td>
<td class="prmDesc">
A
descriptive
error
string
returned
by
the
processor.
</td>
</tr>
</table>
<div>
<em>
No
exceptions.
</em>
</div>
<div>
<em>
Return
type:
</em>
<code>
<a>
void
</a>
</code>
</div>
</dd>
</dl>
</div>
<p>
The
following
example
demonstrates
how
to
convert
JSON-LD
to
a
projection
that
is
directly
usable
in
a
programming
environment:
</p>
<pre class="example">
// retrieve JSON-LD from a Web Service
var jsonldString = fetchPerson();
// This map, usually defined once per script, defines how to map incoming 
// JSON-LD to JavaScript objects
var myTemplate = { "http://xmlns.com/foaf/0.1/name" : "name",
                   "http://xmlns.com/foaf/0.1/age" : "age",
                  "http://xmlns.com/foaf/0.1/homepage" : "homepage" };
// Map the JSON-LD to a language-native object
var person = jsonld.toProjection(jsonldString, myTemplate);
// Use the language-native object
alert(person.name + " is " + person.age + " years old. " +
"Their
homepage
is:
"
+
person.homepage);
</pre>
<p>
A
JSON-LD
Serializer
is
also
available
to
map
a
language-native
object
to
JSON-LD.
</p><pre class="idl">
<span class="idlInterface" id="idl-def-JSONLDSerializer">[<span class="extAttr">NoInterfaceObject</span>]
interface <span class="idlInterfaceID">JSONLDSerializer</span> {
<span class="idlMethod">    <span class="idlMethType"><a>DOMString</a></span> <span class="idlMethName"><a href="#widl-JSONLDSerializer-normalize-DOMString-object-obj">normalize</a></span> (<span class="idlParam">in <span class="idlParamType"><a>object</a></span> <span class="idlParamName">obj</span></span>);</span>
};</span>
</pre>
<div id="methods-2" class="section">
<h4>
<span class="secno">
<del class="diff-old">8.3.3
</del>
<ins class="diff-chg">9.3.3
</ins>
</span>
Methods
</h4>
<dl class="methods">
<dt id="widl-JSONLDSerializer-normalize-DOMString-object-obj">
<code>
normalize
</code>
</dt>
<dd>
Serializes
a
language-native
object
into
a
normalized
JSON-LD
string.
Normalization
is
important
when
performing
things
like
equality
comparison
and
digital
signature
creation
and
verification.
<table class="parameters">
<tr>
<th>
Parameter
</th>
<th>
Type
</th>
<th>
Nullable
</th>
<th>
Optional
</th>
<th>
Description
</th>
</tr>
<tr>
<td class="prmName">
obj
</td>
<td class="prmType">
<code>
<a>
object
</a>
</code>
</td>
<td class="prmNullFalse">
✘
</td>
<td class="prmOptFalse">
✘
</td>
<td class="prmDesc">
An
associative
array
of
key-value
pairs
that
should
be
converted
to
a
JSON-LD
string.
It
is
assumed
that
a
map
already
exists
for
the
data.
</td>
</tr>
</table>
<div>
<em>
No
exceptions.
</em>
</div>
<div>
<em>
Return
type:
</em>
<code>
<a>
DOMString
</a>
</code>
</div>
</dd>
</dl>
</div>
<h3 id="the-normalization-algorithm">
The
Normalization
Algorithm
</h3>
<p class="issue">
This
algorithm
is
very
rough,
untested,
and
probably
contains
many
bugs.
Use
at
your
own
risk.
It
will
change
in
the
coming
months.
</p>
<p>
The
JSON-LD
normalization
algorithm
is
as
follows:
</p>
<ol class="algorithm">
<li>
Remove
the
<code>
@context
</code>
key
and
preserve
it
as
the
<dfn title="transformation_map" id="dfn-transformation_map">
transformation
map
</dfn>
while
running
this
algorithm.
</li>
<li>
For
each
key
<ol class="algorithm">
<li>
If
the
key
is
a
CURIE,
expand
the
CURIE
to
an
IRI
using
the
<a class="tref internalDFN" title="transformation_map" href="#dfn-transformation_map">
transformation
map
</a>.
</li>
</ol>
</li>
<li>
For
each
value
<ol class="algorithm">
<li>
If
the
value
should
be
type
coerced
per
the
<a class="tref internalDFN" title="transformation_map" href="#dfn-transformation_map">
transformation
map
</a>,
ensure
that
it
is
transformed
to
the
new
value.
</li>
<li>
If
the
value
is
a
CURIE,
expand
the
CURIE
to
an
IRI
using
the
<a class="tref internalDFN" title="transformation_map" href="#dfn-transformation_map">
transformation
map
</a>.
</li>
<li>
If
the
value
is
a
<del class="diff-old">Typed
Literal
</del>
<a class="tref internalDFN" title="typed_literal" href="#dfn-typed_literal">
<ins class="diff-chg">typed
literal
</ins></a>
and
the
type
is
a
CURIE,
expand
it
to
an
IRI
using
the
<a class="tref internalDFN" title="transformation_map" href="#dfn-transformation_map">
transformation
map
</a>.
</li>
<li>
When
generating
the
final
value,
use
expanded
object
value
form
to
store
all
IRIs,
typed
literals
and
<a class="tref internalDFN" title="plain_literal" href="#dfn-plain_literal">
plain
<del class="diff-old">literals
</del>
<ins class="diff-chg">literal
</ins></a><ins class="diff-chg">
s
</ins>
with
language
information.
</li>
</ol>
</li>
<li>
Output
each
sorted
key-value
pair
without
any
extraneous
whitespace.
If
the
value
is
an
associative
array,
perform
this
algorithm,
starting
at
step
#1,
recursively
on
the
sub-tree.
There
should
be
no
nesting
in
the
outputted
JSON
data.
That
is,
the
top-most
element
should
be
an
array.
Each
item
in
the
array
contains
a
single
subject
with
a
corresponding
array
of
properties
in
UTF-8
sort
order.
Any
related
objects
that
are
complex
objects
themselves
should
be
given
a
top-level
object
in
the
top-level
array.
</li>
</ol>
<p class="issue">
Note
that
normalizing
named
blank
nodes
is
impossible
at
present
since
one
would
have
to
specify
a
blank
node
naming
algorithm.
For
the
time
being,
you
cannot
normalize
graphs
that
contain
named
blank
nodes.
However,
normalizing
graphs
that
contain
non-named
blank
nodes
is
supported.
</p>
<pre class="example">
var myObj = { "@context" : { 
                "xsd" : "http://www.w3.org/2001/XMLSchema#",
                "name" : "http://xmlns.com/foaf/0.1/name",
                "age" : "http://xmlns.com/foaf/0.1/age",
                "homepage" : "http://xmlns.com/foaf/0.1/homepage",
<del class="diff-old">                "@type": {
</del>
<ins class="diff-chg">                "@coerce": {
</ins>
                   "xsd:nonNegativeInteger": "age",
                   "xsd:anyURI": "homepage"
                }
              },
              "name" : "Joe Jackson",
<del class="diff-old">              "age" : 42,
</del>
<ins class="diff-chg">              "age" : "42",
</ins>
              "homepage" : "http://example.org/people/joe" };
// Map the language-native object to JSON-LD
var
jsonldText
=
jsonld.normalize(myObj);
</pre>
<p>
After
the
code
in
the
example
above
has
executed,
the
<strong>
jsonldText
</strong>
value
will
be
(line-breaks
added
for
readability):
</p>
<pre class="example">
[{"http://xmlns.com/foaf/0.1/age":{"@datatype":"http://www.w3.org/2001/XMLSchema#nonNegativeInteger","@literal":"42"},
"http://xmlns.com/foaf/0.1/homepage":{"@iri":"http://example.org/people/joe"},
"http://xmlns.com/foaf/0.1/name":"Joe
Jackson"}]
</pre>
<p>
When
normalizing
<strong>
xsd:double
</strong>
values,
implementers
<em class="rfc2119" title="must">
must
</em>
ensure
that
the
normalized
value
is
a
string.
In
order
to
generate
the
string
from
a
<strong>
double
</strong>
value,
output
equivalent
to
the
<code>
printf("%1.6e",
value)
</code>
function
in
C
<em class="rfc2119" title="must">
must
</em>
be
used
where
<strong>
"%1.6e"
</strong>
is
the
string
formatter
and
<strong>
value
</strong>
is
the
value
to
be
converted.
</p>
<p>
To
convert
the
a
double
value
in
JavaScript,
implementers
can
use
the
following
snippet
of
code:
</p>
<pre class="example">
// the variable 'value' below is the JavaScript native double value that is to be converted
(value).toExponential(6).replace(/(e(?:\+|-))([0-9])$/,
'$10$2')
</pre>
<p class="note">
When
data
needs
to
be
normalized,
JSON-LD
authors
should
not
use
values
that
are
going
to
undergo
automatic
conversion.
This
is
due
to
the
lossy
nature
of
<strong>
xsd:double
</strong>
values.
</p>
<p class="issue">
<ins class="diff-new">Round-tripping
data
can
be
problematic
if
we
mix
and
match
@coerce
rules
with
JSON-native
datatypes,
like
integers.
Consider
the
following
code
example:
</ins></p><pre class="example"><ins class="diff-new">
var myObj = { "@context" : { 
                "number" : "http://example.com/vocab#number",
                "@coerce": {
                   "xsd:nonNegativeInteger": "number"
                }
              },
              "number" : 42 };
// Map the language-native object to JSON-LD
var jsonldText = jsonld.normalize(myObj);
// Convert the normalized object back to a JavaScript object
var
myObj2
=
jsonld.parse(jsonldText);
</ins></pre><p class="issue"><ins class="diff-new">
At
this
point,
myObj2
and
myObj
will
have
different
values
for
the
"number"
value.
myObj
will
be
the
number
42,
while
myObj2
will
be
the
string
"42".
This
type
of
data
round-tripping
error
can
bite
developers.
We
are
currently
wondering
if
having
a
"coerce
validation"
phase
in
the
parsing/normalization
phases
would
be
a
good
idea.
It
would
prevent
data
round-tripping
issues
like
the
one
mentioned
above.
</ins></p>
</div>
</div>
<div class="appendix section" id="the-default-context">
<h2>
<span class="secno">
A.
</span>
The
Default
Context
</h2>
<p>
The
<dfn title="default_context" id="dfn-default_context-1">
default
context
</dfn>
is
provided
to
ensure
that
there
are
a
reasonable
set
of
prefixes
and
terms
available
to
all
JSON-LD
developers.
Mappings
specified
by
the
<a class="tref internalDFN" title="default_context" href="#dfn-default_context-1">
default
context
</a>
<em class="rfc2119" title="should not">
should
not
</em>
be
overwritten
by
JSON-LD
authors.
All
JSON-LD
processors
<em class="rfc2119" title="must">
must
</em>
load
the
following
context
in
as
the
intial
context
before
processing
JSON-LD
text.
</p>
<pre>
{
  "@context":
  {
<ins class="diff-new">    "@vocab": "",
</ins>
    "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
    "owl": "http://www.w3.org/2002/07/owl#",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "dcterms": "http://purl.org/dc/terms/",
    "foaf": "http://xmlns.com/foaf/0.1/",
    "cal": "http://www.w3.org/2002/12/cal/ical#",
    "vcard": "http://www.w3.org/2006/vcard/ns# ",
    "geo": "http://www.w3.org/2003/01/geo/wgs84_pos#",
    "cc": "http://creativecommons.org/ns#",
    "sioc": "http://rdfs.org/sioc/ns#",
    "doap": "http://usefulinc.com/ns/doap#",
    "com": "http://purl.org/commerce#",
    "ps": "http://purl.org/payswarm#",
    "gr": "http://purl.org/goodrelations/v1#",
    "sig": "http://purl.org/signature#",
    "ccard": "http://purl.org/commerce/creditcard#"
    "@coerce": 
    {
<del class="diff-old">      "xsd:anyURI": ["foaf:homepage", "foaf:member"],
</del>
<ins class="diff-chg">      "xsd:anyURI": ["rdf:type", "rdf:rest", "foaf:homepage", "foaf:member"],
</ins>
      "xsd:integer": "foaf:age"
    }
  }
}
</pre>
</div>
<div class="appendix section" id="acknowledgements">
<h2>
<span class="secno">
B.
</span>
Acknowledgements
</h2>
<p>
The
editor
would
like
to
thank
Mark
Birbeck,
who
provided
a
great
deal
of
the
rationale
and
reasoning
behind
the
JSON-LD
work
via
his
work
on
RDFj,
Dave
Longley
who
reviewed,
provided
feedback,
and
performed
several
implementation
on
the
specification,
and
Ian
Davis,
who
created
RDF/JSON.
Thanks
also
to
Nathan
Rixham,
Bradley
P.
Allen
and
Richard
Cyganiak
for
their
input
on
the
specification.
</p>
</div>
<div id="references" class="appendix section">
<h2>
<span class="secno">
C.
</span>
References
</h2>
<div id="normative-references" class="section">
<h3>
<span class="secno">
C.1
</span>
Normative
references
</h3>
<dl class="bibliography">
<dt id="bib-BCP47">
[BCP47]
</dt>
<dd>
A.
Phillips,
M.
Davis.
<a href="http://tools.ietf.org/rfc/bcp/bcp47.txt">
<cite>
Tags
for
Identifying
Languages
</cite>
</a>
September
2009.
IETF
Best
Current
Practice.
URL:
<a href="http://tools.ietf.org/rfc/bcp/bcp47.txt">
http://tools.ietf.org/rfc/bcp/bcp47.txt
</a>
</dd>
<dt id="bib-RDF-API">
[RDF-API]
</dt>
<dd>
Manu
Sporny,
Benjamin
Adrian,
Nathan
Rixham;
et
al.
<a href="http://www.w3.org/2010/02/rdfa/sources/rdf-api/">
<cite>
RDF
API
</cite>
</a>
Latest.
W3C
Editor's
Draft.
URL:
<a href="http://www.w3.org/2010/02/rdfa/sources/rdf-api/">
http://www.w3.org/2010/02/rdfa/sources/rdf-api/
</a>
</dd>
<dt id="bib-RDF-CONCEPTS">
[RDF-CONCEPTS]
</dt>
<dd>
Graham
Klyne;
Jeremy
J.
Carroll.
<a href="http://www.w3.org/TR/2004/REC-rdf-concepts-20040210">
<cite>
Resource
Description
Framework
(RDF):
Concepts
and
Abstract
Syntax.
</cite>
</a>
10
February
2004.
W3C
Recommendation.
URL:
<a href="http://www.w3.org/TR/2004/REC-rdf-concepts-20040210">
http://www.w3.org/TR/2004/REC-rdf-concepts-20040210
</a>
</dd>
<dt id="bib-RDF-INTERFACES">
[RDF-INTERFACES]
</dt>
<dd>
Nathan
Rixham,
Manu
Sporny,
Benjamin
Adrian;
et
al.
<a href="http://www.w3.org/2010/02/rdfa/sources/rdf-interfaces/">
<cite>
RDF
Interfaces
</cite>
</a>
Latest.
W3C
Editor's
Draft.
URL:
<a href="http://www.w3.org/2010/02/rdfa/sources/rdf-interfaces/">
http://www.w3.org/2010/02/rdfa/sources/rdf-interfaces/
</a>
</dd>
<dt id="bib-RFC3987">
<ins class="diff-new">[RFC3987]
</ins></dt><dd><ins class="diff-new">
M.
Dürst;
M.
Suignard.
</ins><a href="http://www.ietf.org/rfc/rfc3987.txt"><cite><ins class="diff-new">
Internationalized
Resource
Identifiers
(IRIs).
</ins></cite></a><ins class="diff-new">
January
2005.
Internet
RFC
3987.
URL:
</ins><a href="http://www.ietf.org/rfc/rfc3987.txt"><ins class="diff-new">
http://www.ietf.org/rfc/rfc3987.txt
</ins>
</a>
</dd>
<dt id="bib-RFC4627">
[RFC4627]
</dt>
<dd>
D.
Crockford.
<a href="http://www.ietf.org/rfc/rfc4627.txt">
<cite>
The
application/json
Media
Type
for
JavaScript
Object
Notation
(JSON)
</cite>
</a>
July
2006.
Internet
RFC
4627.
URL:
<a href="http://www.ietf.org/rfc/rfc4627.txt">
http://www.ietf.org/rfc/rfc4627.txt
</a>
</dd>
</dl>
</div>
<div id="informative-references" class="section">
<h3>
<span class="secno">
C.2
</span>
Informative
references
</h3>
<dl class="bibliography">
<dt id="bib-MICRODATA">
[MICRODATA]
</dt>
<dd>
Ian
Hickson;
et
al.
<a href="http://www.w3.org/TR/microdata/">
<cite>
Microdata
</cite>
</a>
04
March
2010.
W3C
Working
Draft.
URL:
<a href="http://www.w3.org/TR/microdata/">
http://www.w3.org/TR/microdata/
</a>
</dd>
<dt id="bib-MICROFORMATS">
[MICROFORMATS]
</dt>
<dd>
<a href="http://microformats.org">
<cite>
Microformats
</cite>
</a>.
URL:
<a href="http://microformats.org">
http://microformats.org
</a>
</dd>
<dt id="bib-RDFA-CORE">
[RDFA-CORE]
</dt>
<dd>
Shane
McCarron;
et
al.
<a href="http://www.w3.org/TR/2011/WD-rdfa-core-20110331">
<cite>
RDFa
Core
1.1:
Syntax
and
processing
rules
for
embedding
RDF
through
attributes.
</cite>
</a>
31
March
2011.
W3C
Working
Draft.
URL:
<a href="http://www.w3.org/TR/2011/WD-rdfa-core-20110331">
http://www.w3.org/TR/2011/WD-rdfa-core-20110331
</a>
</dd>
</dl>
</div>
</div>
</body>
</html>
